What worried me about Erlang was that when a process dies and gets restarted, the message queue for the old process gets thrown away. Neither the sender(s) nor the new process can tell how many messages were lost.
If you care about reliability of the delivery, you can do a number of things: do a single call, wait for response and retry if needed, or store the messages in mnesia and only notify there's something to pick up (pull scenario with ack), or do a number of other possible things.
Lost messages are a fact of life really - the same will happen with any other system - either you persist the message and ack the reception on every stage or you risk dropping the queue.
Yes, that situation is usually handled by using an ETS table to store messages (essentially, you create an internal message queue for the supervision tree).
On the other hand, there's no guarantee the message arrived in the first place (especially when using multiple nodes) unless you use ack patterns.
