Здравствуйте, _hum_, Вы писали:

__>ммм...с каких пор "короче" стало приоритетнее при написании прог, чем "понятнее"? мне, например, не очень нравится, что вместо того, чтобы писать что-то наподобие
__>

__>if(0 == proc_rank)
__>{
__>  std::vector<int> MPIGatheredValues(nMPIProcessesCount, 0);

__>  MPI_Gather(MPIGatheredValues.data(), 1, MPI_INT, 0, MPI_COMM_WORLD);

__>  //<working as for a root process>
__>}
__>else
__>{
__>    const int value = <something>;

__>    MPI_SendForGathering(&value, 1, MPI_INT, 0, MPI_COMM_WORLD);

__>    //<working as for a non root process>
__>}
__>

Если не нравится, то реализуйте свои версии MPI_Gather и MPI_SendForGathering, и работайте с ними. В чем проблема?
Будет у вас хорошая обертка, люди начнут пользоваться ею.

__>приходится мешать все в кучу, наподобие
__>

__>std::vector<int> MPIGatheredValues(nMPIProcessesCount, 0);

__>const int value = <something>;

__>MPI_Gather(&value, 1, MPI_INT, MPIGatheredValues.data(), 1, MPI_INT, 0, MPI_COMM_WORLD);
__>

Это непривычно поначалу, но мне особых проблем не доставляет. К тому же, второй вариант выглядит компактней и понятней. Ветвления воспринимаются сложнее.
Все-таки MPI — это дитя научного сообщества, а не программистов, так что тут могут быть немного другие приоритеты.

__>UPD. Возникла мысль — может быть, так сделано, для того, чтобы гарантировать, что всегда будет отсылающий и собирающий?

Программист гарантирует наличие отправителя и получателя, функции сами по себе этого сделать не могут.