Missing the AF_BUS

Also it's worth noting again that the design tradeoffs in dbus are almost all copied from X11. Messages between two processes are guaranteed to stay in the order sent, network errors are handled by just disconnecting and starting over, there's a central server that all the apps use to talk to each other, it's a binary protocol, there's a "selection" (bus name) concept used to acquire/release/locate resources, similar authentication mechanisms, server is located via environment variable, blocking round trips are discouraged (mechanisms are provided to avoid them), people use both almost exclusively on same-machine or at least a LAN, etc.

So most problems and solutions that apply to X11 will also apply to dbus.

I think the tradeoffs and guarantees made here are a pretty good guide to what desktop/mobile app developers want when they're writing a UI that's implemented as a "swarm of processes" (as all the X desktops are). Framed another way, this is what a local IPC system has to provide in order to support relatively reliable application code in this context. However, these tradeoffs are probably inappropriate for systems distributed over the internet or even over a cluster.

Based on dbus list traffic there seem to be development situations where similar tradeoffs make sense but the inherent slowdown of the central dispatch daemon is a problem. That's where kernel-accelerated dbus-like-thing would make sense maybe.