I have the exact same obsession, along with obsession with programming languages and software design in general (especially simplicity and composability). but I don't associate feelings with it. I learn about OSs because I don't like magic; I need to understand how things work down to the hardware level. In the process, I build pieces of kernels in different languages to solidify my understanding.
I came to the conclusion that all current kernels have the same philosophy, basically there's a concept of process (aka address space), threads, virtual memory, interrupts, i/o devices, concurrency and synchronization, etc. Unix/BSD/Linux, macOS (BSD with a Mach kernel), Windows NT (a descendant of VMS), all have more or less the same core concepts. This is why I also started looking outside those systems, and started exploring mainframe operating systems and their history (starting from IBM OS/360 all the way to z/OS).
I started asking myself what if there was a different way to design an operating system. What is a "program"? Does every program have to be loaded into its own address space? Can we be more efficient when composing small programs together by colocating them in the same address space (think of piping without IPC)? How can we maintain protection in this case? Can we leverage memory protection keys to help there? Can programs define metadata about how they should be integrated in bigger flows (think execution DAGs)? Can we blur the difference between CLI, GUI, and server programs such that all of them are considered pieces of functionality that is registered system-wide and invoked in the context of other "programs" (think of embedding behaviour of one program inside another). Can we think of interrupts as hardware callbacks? Can we structure interrupt handlers as async workers in a unified programming model? How does that influence async i/o and events design?
To enable this kind of thought, I think we'll need a different breed of programming languages. Can we have a language that doesn't just focus on control flow, data types, etc. and instead allow us to define large, complex system behaviour in a way that guides the design, rather than implement the design? This is what I'm obsessed with, and I still don't have an answer.