Collect only handles the last batch of work (a number of messages never bigger than max_concurrent). Within the main fold, messages are received in the order they arrived (see line 328). I can this collection of the last batch for 1.4, but I could see that as something easy to mess up right before shipping this.

I'm aware of the perils of selective receives in this general purpose utility, but thought that any application sensitive to that should run pmap in a separate process that will only collect pmap messages anyway. That way it can handle its mailbox in whatever way is more efficient (say a gen_fsm would spawn a function that ran pmap and sent an event back to it, or a gen_server would send itself back a call, etc).

In the case of initialization, we have already been blocking here for hours at a time without processing messages, so I don't think that this particular case is any worse. It should be a lot better now just due to the fact that it will likely block for a 10th of the time it did before.