I'm not a fan of using selective receive on `Pid` here. That can lead to `O(N^2)` mailbox scans, as well as keeping items in the mailbox longer then necessary. To illustrate, let's say we have pids A-D, but due to worker timing or whatever we receive messages in the order D-A. The first iteration of `Collect` is going to do a `receive {pmap_result, <A>, R}`, skip over messages D-B, find A, return. Then for B it'll start over, re-scan until it finds B at the end, return. Rinse/repeat for the rest. Likewise, if A took longer than the other workers, we'd stick around waiting for A while keeping D-B messages sitting in the mailbox the entire time.

For vnode init, this may not be a major issue. But, given that `pmap/3` is designed to be a general purpose utility function, we might as well consider what happens if someone decides to use 1000 workers or something. Really don't want to scan 1 million messages in the worst case.

Any reason you can't just do a receive on `{pmap_result, _, R}`, thus handling each response in the order they are sent? It looks like you end up sorting the results on line 297 so you're not particularly sensitive to how you end up constructing `All`.

On a different note, I really wish we could use optimized receives in both this `pmap/3` as well as the older `pmap/2`. But, the strict requirements of how you must structure your code to get the Erlang compiler to use the optimized receive won't work for the way either of these pmap implementations are coded. This is unfortunate, as each `receive` for the `pmap_result` is going to scan over all non-pmap messages in the mailbox. This is kinda annoying for the `riak_core_vnode_manager` which receives 100s to 10000s of messages regularly. One of the top serialization points in all of Riak.

One option would be to do the pmap itself in a separate process. Ie. calling pmap spawns a process that then spawns the workers, waits for results, then sends the combined results back to the original process. This would decouple the calling processes mailbox from the pmap process. Anyway, food for thought.