> The whole point is the decoupling of userland from the kernel.

Decoupling is good; but this isn't just decoupling, it's encapsulation. The problem with graphical "shells" / userland object systems is that they treat the OS kernel as something to run on top of — to abstract away and mostly ignore — rather than something to implement themselves in terms of. The shell isn't described to the kernel in a way where shell objects are in any way "visible" or "accessible" to the kernel. Instead, in the major OSes, shell state (shell objects, namespaces, etc.) lives only in the shell; as far as the kernel is concerned, it doesn't exist.

Now, I have no opinion on whether shell state should actually "live" in the shell, vs. in the kernel (or in kernel-accessible subsystems, if we're talking microkernels.) It's probably better engineering-wise to keep shell-level state in userland.

But the kernel should still be able to interact with that userland shell state. The shell should be built such that it's easy for the kernel to enumerate and manipulate its objects. And the kernel should be built to know about the stable abstractions that make up the shell object runtime.

Where we are today, with shells opaque to kernel understanding:

• The Windows CLI sees my Windows network shares, and mounted drives from disk extensions, but not my Windows shell namespaces, nor my volume-ID-only mounts

• The macOS Finder can treat bundles as files (for e.g. copy/move operations, atomic backup, last-accessed versioning, etc.), but the BSD CLI just sees .bundle directories and needs special help to emulate the Finder approach

• Windows and macOS both treat directories containing only file-reified shell-level metadata (Desktop.ini/Thumbs.db, .DS_Store, AppleDouble files) as "empty" for purposes of preview / overwrite / merge / safe deletion – but their CLIs don't

• Both Windows and GNOME allow me to browse within compressed files, but only when going through the shell, not through the CLI, and not even when going through older APIs like Win16

• The Linux binfmt_misc driver needs shebang lines, despite the existence of file extensions, MIME-type xattrs, and shell file-association preferences tables

• Files marked as "quarantined" in macOS just look like regular files in the CLI, and no CLI program chokes on them, allowing scripted operations against such files to get quite deep in, until they hit some Cocoa-enabled subtask like codesign(8) that suddenly chokes on the quarantined input

I'm not totally sure on what a good solution to all this would look like, but I imagine it'd look like a replacement of all the custom kernel-to-userland callback APIs with a sort of "kernel-supported COM" where the kernel can talk to userland processes as if it were just another userland process making a COM request; and then the kernel can end up holding onto userland process COM object proxy-handles, passing them around, putting them into other kernel structs, etc.

Ideally, I think, the kernel would be responsible for declaring the contracts/interfaces that all shells running on that OS must implement themselves in terms of. Then "shell objects" would just be pure-userland kernel objects (i.e. defined by kernel base-classes, but with no kernel code in their codepath at runtime), sort of like Linux vDSOs are pure-userland kernel drivers.

Linux isn't really "ready" for this change—there are some gnarly legacy kernel-structs that need to retain their shapes and semantics, due to them being directly userland-visible without an intermediate view layer. But WinNt could totally do this, implemented almost entirely in terms of opaque kernel-object handles as it is. Nt-level structs don't matter one whit to userland, so they're free to be changed to retain opaque shell-level references. (I believe this was part of Midori's design?)