Hmmm, I had forgotten this security-orientation of Mach ports. But that was not the thing that I was thinking to.
What I found nice in Chorus API was the fact that msgboxes (IIRC the name) - ie. communications endpoints - acquired in one thread (process) were encaspulating all the queuing, buffering, parameters and error signaling from the application level. So, for example, you could rely on them for holding message(s), properly ordering error reports or interrupts with messages anterior to errors, etc.
A nice feature too (but primarily system-wide) was that these msgboxes were simple system-wide IDs. In a distributed or concurrent application, initialization was therefore very straighforward: processes send their msgboxes IDs to each other. Hence, it was pretty easy to write/start complex applications without relying too much on correct static configurations (of various TCP/UDP port numbers for example).
Well, maybe I over-emphasize this (nostalgia...;-). 0MQ sockets seems to offer a nice encapsulation too from what I see of the API documentation. And real multicast support is not so common...
Do you think it would be possible to find a (clean&generic) way to get rid of explicit transport selection in zmq_bind() - or am I just dreaming?