That's the downside of having VM-based system emulation easily available: People who think that userland scripting is too complex take this complex functionality that occurs in semi-critical areas into C code, possibly into the kernel. Because they can debug it just fine when they're trying it out in the VM.

Fast forward: the thing gets deployed by default on Ubuntu (or SuSE, or Fedora ... whatever), and people start getting hard-to-debug crashes. Someone, somewhere, will run into an ugly corner case. Or some app that has been quietly chugging along in the corner suddenly causes serious breakage.

That's the moment when you get all those bugs closed with WORKSFORME, INVALID or other non-solutions, because users can't get the debugging info on their production system, and the enthusiastic developers can't reproduce it on their system and are not as enthusiastic about figuring out which obscure corner case caused the sytem to misbehave.

As an example, see here: https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/48... Under various conditions, the boot process just gets stuck (e.g., when something has juggled the hard drive letters and what used to be /dev/sda is now /dev/sdb and vice versa, or you have a routine fdisk check, or something else), and when you switch off the splash screen (or don't have it switched on at all, for obvious reasons), all you see is the (spurious) message from ureadahead-other. Net result: this kind of spurious hangs on boot, which were reasonably easy to diagnose in the time of SysVinit, are now a serious PITA and the developers which are responsible for the boot process don't give a fart because people don't have the knowledge that's needed to debug the subtle interplay of dbus, upstart, plymouth (it's obvious that "plymouth" is the splash screen software and not a device driver for a CRT-based face tanning, isn't it?), and possibly others. (Full disclosure: I twice or thrice spent a whole morning figuring out a random boot problem without getting anywhere. After several hours, I found out that part of the problem was caused by mountall not finding something, then asking whether you want to continue booting without actually displaying a prompt that says so. Back then, I managed to find the corresponding bug on launchpad among the 5+ bugs about weird, hard-to-diagnose boot problems where all you see is the ureadahead-other message).

TL/DR: if you consider moving X into the kernel, please imagine yourself in a situation where X breaks in production and you have to guide a user through the debugging of X and various assorted components that talk to X in order to find out whether it's X or Y or ABC and what exactly is breaking. If that thought would give you a bad dream, please refrain from putting X into the kernel. Thank you.