Long ago, an OS I worked inside had a tool which took shared library indirect calls, and wired them out so you did not have a nested indirect function call cost, but went direct from the call to the backend without the pass-through the null function mapping into the specific .so library. It made things faster by one layer of the onion skin.

Strip, as a UNIX tool removes the textual crap in a debuggable binary, to leave behind only the bits you needed.

It feels to me like if you can do runtime code call checks, and confirm which actual calls you make, then stripping the bits of libc and associated libraries out, being left with only the strictly required calls, and then by extension the syscalls, and then by extension the kernel elements, is actually possible a lot of the time.

So, library -> reduced library -> reduced calls -> reduced syscalls -> reduced kernel state is a sequence or set or something, of applied minimisations which can be done, if you can predict all the call paths in your code and their dependencies.

But then its not a generic OS any more: its an application specific binding to a general purpose CPU.

Why not go all the way, and work into the ALU and remove the bits you don't need? And then go into the micro code, and the associated FPGA, and everything else..