For more half-baked ideas, see the ideas tag.
The Linux kernel:
/boot/vmlinuz-3.11.9-200.fc19.x86_64
5 MB of highly optimized code that runs the world’s computers. You can copy it around and boot it on different hardware.
No wait, that’s all wrong. I’m forgetting about the modules. There are another 2832 files in /lib/modules/3.11.9-200.fc19.x86_64 and without them this kernel will hardly function.
It’s nice to be able to copy the kernel around — to compile it on fast x86-64 and run it on slow ARM, or to run the host kernel in a VM, but all those module files make everyone’s lives a lot more complex.
So my half-baked idea is this:
Combine all the modules into a single file, let’s call it /boot/modules-3.11.9-200.fc19.x86_64. This file might start off as an ext4 filesystem which can be loopback-mounted on /lib/modules. Eventually I’d hope that the module tools could load modules from the file directly.
Now you can happily cross-compile and copy just two kernel files from x86 to ARM or into your VMs, and that’s a lot less hassle.
Richard WM Jones 
Forgive my ignorance, but isn’t initrd for this purpose?
To a degree. You don’t want your initramfs being a gigabyte in size. Of course, copying around a separate file of that size isn’t really all that great either. Distribution kernels are the worst case scenario here because they build way more than each individual person need for their specific machine.
There’s a whole bunch of design decisions in Linux/Unix that are less than simple (initramfs being IMO even more of a pain than the modules masquerading in the userspace library directory). It’d be great if the kernel stuff (Linux only) could be pushed into a separate /boot partition and the userspace (heck isn’t that bit Unix and thus stunningly cross platform and able to run anything without recompiling?) kept isolated from particular kernels.
On the other hand, all these things have a reason (or at least an excuse)…
Yup, history has a peculiar way of evolving baroque designs. My first experience of a kernel which had modules was with Microware OS-9 which had a far cleaner design.
Please.
Isn’t distribution packaging the sollution? Rpm, deb, tgz.. whatever. Just one or two files you could install on another machine.
No. For supermin we have to copy the modules from /lib/modules (ie. after they are installed). For cross-compiling there’s no easy answer at the moment but distro packaging is essentially irrelevant.
Fortunately, the pioneers of computing came up with a convenient method for combining multiple discrete things into a single, conveniently manipulable item like this. It’s called a ‘directory’, and sure enough, you’ll find all the modules for a given kernel inside one:
[adamw@adam audio]$ ls -R /lib/modules/3.12.3-1.fc21.x86_64/
(lots of modules)
Look! It’s a single object containing all the kernel modules, which you can easily copy around to different places…
It’s not that convenient. Read the post and have a look at the complex code in supermin to see how much complication this causes.
The 9p option works well and saves on disk io.
libguestfs is sufficiently well-defined that you can use a predefined appliance kernel (I thought that was the point, given your focus on performance), but the depmod-based approach of dracut/initramfs-tools is still available. Dumping the entire directory in the supermin manifest is also an option, and that builds 2-3 files.