>>51
Erlang manages its own process priorities, if you care to fiddle with those settings. Its process switching time is incredibly short, since it doesn't have to swap CPU states, so it screams through your process list very quickly.
As for your 2nd paragraph, what's the problem? The sender can only know anything if there is a response from the receiving end. Take these scenarios:
1) Message went out on the wire, receiver didn't get it yet
2) Message is sitting in the receiver's inbox
3) Receiver pulls the message from its inbox
4) Receiver does its work and sends ACK at the appropriate stage, early on or at the end
Responding to 1-3 really isn't meaningful at all in tracking the call's progress (unless you're doing some incredibly low-level tuning) since the receiver can error out or crash afterwards without the work getting done. The 4th is really the only useful way of acknowledging reception, and by definition requires the receiver to trigger when it's appropriate to send it.
GUIs and other systems have been doing message-queue processing since they've been invented, and the fear of message overflow has never been a huge concern.