On the light experimentation front, a longstanding goal of mine is to see NixOS support multiple kernels, because the status quo of having to cobble together a userland from parts for each kernel is a huge productivity drag. Having a "userland assembly toolkit" that lets you plan out what software you want to support with what patches could dramatically lower the barrier to entry.

Trying to carve out a driver layer would also be fantastic. This should be analogized to LLVM making a reusable compiler backend, and the dramatic effect that had on programming language diversity allowing things like Rust to come into existence.

At the same time, kinda what I am saying here is that maybe it isn't quite a local maxima.

Today most kernel work is motivated by performance, maybe security. The mistakes that are already worked around with more ugliness in other layers is usually not prioritized --- we have the workarounds, what's the problem? If more OS work was thought of in productivity terms --- we want to make writing correct, secure, performant, etc. software easier and more natural --- I think we would find the gradient might be bad in many directions, but still good in others.

The stuff I include here is are all things that I think could be refactored into existing "heritage" kernels without much difficulty. I actually looked a bit at FreeBSD and Linux for the process-spawning parts, for example. Just need to slice up the fork/exec code and then call it in a different order.