ZFSBootMenu "reuses kernel code", too. It actually reuses kernel binaries, because it is nothing more than a collection of init scripts in a small Linux initramfs to enumerate ZFS filesystems and allow you to kexec one of the kernels found within. When using `generate-zbm` to build a custom image, your copy of ZFSBootMenu will use the very same kernel and ZFS driver that your system is running. When using the the prebuilt UEFI or separate kernel/initramfs that we provide as a convenience, the image is built from a Void Linux container using whatever kernel and ZFS driver was current at the time the container image was created.
I'm not sure what the complaints are about mounting filesystems. Unless you want to raw-dump your kernel and other components necessary for booting to some known offset on the disk, you'll always have to walk some filesystem to find the kernel. This even happens in the FreeBSD boot process, where one of the stages has to go looking at the filesystem for a kernel.
I think you misunderstand what ZFSBootMenu does. It doesn't manage any snapshots. It refuses to do anything to any file system that isn't clearly marked as an operating system root. (There are a few well-defined criteria that must be met before ZBM will even attempt to determine if a filesystem has Linux kernels that it will allow you to boot.) Once it identifies one or more file systems that contain bootable Linux kernels, it allows the user to select a kernel from one of those file systems for booting. It also allows the user to enumerate snapshots of those bootable file systems and boot from them via ZFS cloning (with or without promotion) or a send-receive duplicate that avoids interdependencies.
Yes, Nix manages a history of past system instances and NixOS modifies the bootloader to present each of these states as a bootable option. This maps loosely to the ability to elevate ZFS snapshots to boot environments in ZBM, but the functionality is not redundant. In fact, it isn't even a compatible alternative---we haven't found a good way to make ZBM boot NixOS. If you want NixOS, you're booting the NixOS way.
Nix is a very interesting concept that offers several advantages. It also has drawbacks. For example, it can be inordinately complex to manage small deviations from upstream configurations that aren't represented by pre-existing options. (Ever try to add a single line to a PAM configuration file in Nix?)
The Nix way of booting falls apart should you want to have multiple Linux distributions coexisting on a single pool. NixOS works best when you have complete buy-in. ZFSBootMenu doesn't care; if it can find kernels in the `/boot` directory of a ZFS filesystem, it will show you the filesystem and let you boot it.
ZFSBootMenu can also render itself as an ordinary initramfs image and maintain a separate copy of the kernel it's built against. These can be launched with some intermediate bootloader (e.g., rEFInd, syslinux or systemd-boot) or the kernel's built-in EFI stub can be run from the firmware. However, some Dell firmware seems incapable of properly passing command-line arguments to UEFI executables; a UKI that encodes its command line is needed on affected systems.
This was not the flashpoint, and the comment was not an attempt to make fun of xtraeme's situation. I had no knowledge of his situation until long after that comment was made, pushed to the fortune file, and reverted.
Watching the situation unfold reminded me acutely of the arguing and escalation I witnessed in the aftermath of my parents' divorce and the gradual destruction of my father's second marriage.
I made the comment in an attempt to lighten the mood in a Void IRC channel while a situation that nobody wanted in the first place spun out of control.
Knowing how the comment was perceived, I regret making it. I also regret that it has now been immortalized by another user in the commit logs of void-packages.
I'm not sure what the complaints are about mounting filesystems. Unless you want to raw-dump your kernel and other components necessary for booting to some known offset on the disk, you'll always have to walk some filesystem to find the kernel. This even happens in the FreeBSD boot process, where one of the stages has to go looking at the filesystem for a kernel.