There is no complete theory of what features should be included within a software product, or what features should be left out. It’s more of a question of complex technical trade-offs and product-roadmap decisions taken in response to market competition, a mixture of interests and consequences that sets the present boundaries of software products. For instance, the detailed analysis of the evolution of operating systems reveals a rich history of shifts and reversals: on one hand, the operating system supplier must offer equal and free access to as much services as possible to the ecosystem of software developers, with the intent to avoid code redundancies for basic functionalities, so the platform benefits from the various network effects (two-sided, direct and indirect), but also taking into account that bloating the kernel with too much code may perhaps increase maintenance and support costs to extraordinary degrees; but on the other hand, a too small kernel also reduces lock-in. The best starting point for understanding the different forces and interests that came into play is the following paper:
Another, and less strategic viewpoint, considers the answer of the correct place for a given functionality (exact processor ring, kernel/user mode and/or if it should be a library provided by the OS) a matter of custom and efficiency: for example, the need to get rid of the latency from user-mode calls to the kernel has always pushed more functionality into it, together with satisfying the demand of a basic security model. But these are just examples of the multiple balances that have to be struck, and what’s really interesting is to search for the non-obvious trade-offs and how they have given rise to different cultures of computing. Consider the case of the graphical interface and the window system: in the Unix tradition, a minimalistic approach was taken in that most of it is taken out of the kernel and even relegated to third parties (X Foundation), but the Windows tradition opted for the opposing approach, so it includes the Windows Manager and the GDI framework in kernel space; the consequences are long and lasting, even disastrous in the security space, like how any X client can dump the content of an arbitrary window, including the ones it did not create. Also note that the precise breakdown of the barrier of user and kernel mode varies over time: traditional kernel-mode components are being moved into user-mode processes, like the User-Mode Scheduling for threads and the User Mode Driver Framework. But at the end, the truth is that the forces shaping the design of operating software tend to be more of economic than technical nature, as exemplified in the discussions collected in the following paper: