I don’t really see the point in using the ESP for anything serious. Many of the arguments are also super weak, like the one about /boot/efi/ being nested (in how many cases is this actually important to anyone and anything?). The ESP size issue successfully prevents the real world adoption of this, since Linux kernels are 50-100 MB each, which means you could maybe fit one on your average ESP, and good luck convincing real users to reinstall Windows just to make some Linux guys happy.
Instead, I would prefer a different approach. An approach that can be seen in Windows and macOS, that is: no user serviceable parts inside. It would work like this:
* Keep two partitions.
* ESP contains a simple program (let’s call it stub), whose only job is to call the real boot loader on /boot.
* The stub is simple (minimum user interaction) and doesn’t need updating very often. It has drivers/support software for storage media and some reasonable file systems (VFAT, Ext4). It may also support some simple form of disk encryption if desired.
* The real bootloader (as well as any kernels) live on the separate /boot partition. The bootloader can do all the fancy things it wants, it can display a fancy wallpaper, support mouse input, and so on.
* The ESP is not auto-mounted, might not even be listed in /etc/fstab.
* Whenever the stub is updated (which would happen rarely, since it’s meant to be simple and minimum), some post-install scripts would mount ESP in any location they please (be it /run/{uuid.uuid4()}), copy over the new stub, and immediately unmount it.
Simpler, safer, will make it harder for rogue software or `rm -rf /*` to mess up the booting of the system, and will not require any changes to existing partition tables.
Instead, I would prefer a different approach. An approach that can be seen in Windows and macOS, that is: no user serviceable parts inside. It would work like this:
* Keep two partitions.
* ESP contains a simple program (let’s call it stub), whose only job is to call the real boot loader on /boot.
* The stub is simple (minimum user interaction) and doesn’t need updating very often. It has drivers/support software for storage media and some reasonable file systems (VFAT, Ext4). It may also support some simple form of disk encryption if desired.
* The real bootloader (as well as any kernels) live on the separate /boot partition. The bootloader can do all the fancy things it wants, it can display a fancy wallpaper, support mouse input, and so on.
* The ESP is not auto-mounted, might not even be listed in /etc/fstab.
* Whenever the stub is updated (which would happen rarely, since it’s meant to be simple and minimum), some post-install scripts would mount ESP in any location they please (be it /run/{uuid.uuid4()}), copy over the new stub, and immediately unmount it.
Simpler, safer, will make it harder for rogue software or `rm -rf /*` to mess up the booting of the system, and will not require any changes to existing partition tables.