1) the lack of a useful backpressure mechanism on mailbox size is a long standing issue in Erlang. It tends to not be too big a problem in practice, since overflows come from simple bugs that stop your system immediately and are found during development, rather than subtle conflicts that lurk around.
2) Erlang clustering isn't really supposed to withstand splits. Erlang was built for phone switches before the internet and while it is "distributed", the clustering is between a few boards or boxes that are wired together in the same rack, maybe over a hardwired LAN, not through the viscissitudes of a routed network like the internet connecting remote cities. So the cluster has to keep running if a node is out, but the idea is that node has crashed (or maybe equivalently, the network wire has been cut), not that the connection between nodes has somehow become flaky in a way that can be fixed with retries. Of course ordinary network connections are normally supervised under OTP and they do get restarted.
I actually really like the "mailboxes are on the receiver's heap" thing. One of the big reasons why Go's channels bother me is that they're bounded. This makes things far more complicated, because they're not bound to a go routine, and an irresponsive goroutune can't get terminated.
2) Erlang clustering isn't really supposed to withstand splits. Erlang was built for phone switches before the internet and while it is "distributed", the clustering is between a few boards or boxes that are wired together in the same rack, maybe over a hardwired LAN, not through the viscissitudes of a routed network like the internet connecting remote cities. So the cluster has to keep running if a node is out, but the idea is that node has crashed (or maybe equivalently, the network wire has been cut), not that the connection between nodes has somehow become flaky in a way that can be fixed with retries. Of course ordinary network connections are normally supervised under OTP and they do get restarted.