> This code is usually there for a reason and a unikernel will have to implement large swaths of this code anyway.

The largest part of a monolithic kernel today is devices drivers, by far.

> Networking isn't trivial and I don't think anyone will be reimplementing the TCP/IP, UDP/IP, ARP, DHCP and more stacks without breaking in a few bugs themselves.

Sure. And then more people will use those stacks, and they will get better. The more the merrier, we have too much of a software monoculture anyway.

> The only real advantage I see for unikernels is that because all the hard work is done by the hypervisor they don't have to bother implementing device drivers

This. People continually underestimate the amount of work required to support the hardware ecosystem. This is also why rump kernels (note, not the same term as the unikernel known as Rumprun) are such an achievement, also very much underappreciated.

Well, yes, a lot is device drivers, but not most. You can make the Linux kernel, for example, minus almost all drivers. That usually slims down the kernel image by a few megabytes. More when you drop various other drivers and subsystems you technically no longer need. Though on most modern systems almost 80% of the drivers are modules and won't be loaded if not needed. The diskspace they consume is irrelevant for most intents and purposes (below 100MB on my distro).

> The more the merrier, we have too much of a software monoculture anyway.

Linux and some other kernels allow userspace apps to have their own network stack in userspace, latest kernels allow even larger sections of the networking subsystems to be entirely in userspace.

I think this approach should be favored over a unikernel since it uses the natural x86 privilege seperation between userspace and kernel.