I appreciate the insight in this comment! I see your problem, and I offer an answer (I daren't call it a solution): there is no surefire way to make an interfac

I appreciate the insight in this comment! I see your problem, and I offer an answer (I daren't call it a solution): there is no surefire way to make an interface/abstraction withstand the test of time. It just doesn't happen, even across just a few paradigm shifts, at least not without arbitrary costs to performance, observability/debuggability, ease of use, and so on. The microkernel (in the spirit of Liedtke)/exokernel philosophy tells us to focus on providing minimal, orthogonal mechanisms that just barely allow implementing the "other stuff". But unless a monolithic system is being built for one purpose, "the other stuff" isn't meaningfully different from a microkernel; it has different "hardware" but must itself impose minimally on what is to be built above it. We build layers of components with rich interactions of meaningful abstractions, building a web of dependencies and capabilities. There is no accidental complexity here in this ideal model; to switch paradigms, one must discard exactly the set of components and layers that are incompatible with the new paradigm. Consider Linux async mechanisms. They are provided by a monolithic kernel that dictates massive swathes of what worldview a program is developed in. When select was found lacking, it took time for epoll to arrive. Then io_uring took its sweet time. When the kernel is lacking, the kernel must change, and that is painful. Now consider a hypothetical microkernel/exokernel where a program just gets bare asynchronous notifications about hardware and from other programs. Async abstractions must be built on top, in services and libraries, to make programming feasible. Say the analogous epoll library is found lacking. Someone must uproot it and perhaps lower layers and build an io_uring library instead. I will not say this is always less pain that before, although it is decidedly not the same as changing a kernel. But perhaps it is less painful in most cases. I do not think it is ever more painful. This is the essential pain brought about by stability and change.