I don't think that word means what you think it means.

Microkernel = move all the code OUT OF the kernel.

These slides are about moving all the code INTO the kernel.

Putting your application logic into the kernel would be more like a unikernel I guess?

I don't think that's the right way to think about it. We believe our code to be functionally decomposed when it's in separate functions that we can reason about and test in isolation, but when compiled, the functions may be inlined, may have constant propagation, may even be evaluated at compile time.

If the kernel, at its core, is just an execution environment for sandboxed programs that are sent into it, the source-level decomposition is solid, and the kernel is micro, relatively speaking, to the total amount of functionality. Drivers etc. can still be developed outside the kernel and need only interact with the sandbox API. Drivers may be upgraded live if the sandboxed programs can be replaced. The point of sandboxing is to ensure (ideally prove) that there can be no crashes due to violations of memory safety, or busy loops.

Microkernels are about reducing the amount of code run in kernel space.

Is this project moving things from user space to kernel space? If so it's the opposite of a microkernel.

E.g. if the Linux kernel becomes aware of the application layer, that really does sound like stuff that used to run in user space is now running in kernel space.

For example, nebulet https://github.com/nebulet/nebulet wanted to run everything in ring 0, but "userspace" was WebAssembly code that had been compiled by "kernelspace" to run sandboxed in ring 0

If a CPU architecture was implemented to only offer ring 0, would a microkernel be impossible? Or would we accept this concept of kernelspace/userspace being implemented in software?