2) They want the ability to insert a broker that manages permissions among the peers, but have the kernel enforce those permissions on a per message basis so the broker doesn't become a bottleneck. That's not easy to with the filesystem.

I mean, strictly speaking it's theoretically possible using the file system considering that in practice the only real broker would be systemd with a fixed set of policies, so theoretically the traditional Unix model of user, group, and supplementary groups would suffice by assigning users and processes into the proper groups, and binding message files into protected group-readable directories. But for whatever pretense, people want the solution to implement a system of opaque, ephemeral identifiers/capabilities.

It sort of reminds me of SMF, launchd, systemd, and similar changes. For example, I was installing Solaris 11.3 on a VM yesterday and was trying to figure out how to set the hostname. You used to set it by storing the hostname to /etc/nodename. Now it's stored in some opaque tree data structure deep in the bowels of SMF, which you set with some long and impenetrable command-line utility invocation. You can still set /etc/nodename; if no hostname is configured then SMF will initialize the hostname from /etc/nodename and delete the file. It boggles the mind.

* Inotify events are coalesced. Great for notifications, may be bad for discrete messages.

* The sender may want information about # of messages sent, synchronous delivery, etc.