Running in user space doesn't automatically decouple things; dbus is a user space process, but restarting it is traumatic because half the system uses it.

That's because dbus hasn't been written with no-downtime restarts in mind, but it's not that challenging to implement, especially when client apps are interfacing through (UNIX) sockets.

It's not dissimilar to writing zero-downtime web services.

Sure, but that's not a function of user/kernel space; Linux has live patching and dbus doesn't. It would be cool if fuchsia makes every OS component support non-disruptive updates, I'm just trying to point out that that doesn't automatically follow from running parts in user space.

Good point, updated my reply. While Google don't explicitly say that they want to support run-time updates of the kernel and OS; it's implied in their system architecture that such is the case.

Very difficult to do that though without enormous effort in transparent state persistence across restarts. Restarting even something with a very simple non-transactional API and state base like a filing system requires persisting all the file handle state, and that's the best case. Restarting a UI subsystem is much harder still because the apps may have a lot of uploaded state, things may need to be changed transactionally, etc.