You don't need 2 EFI boot partitions for this -- you can have multiple boot loaders in the same EFI partition, each with its own entry in the boot menu. In fact, this is how I boot: the default entry boots the linux kernel directly from the EFI partition (some UEFI implementations require the kernel to have a .efi extension, others don't), and I have separate fallback entries for refind and shellx64 in case I need to boot with different kernel parameters.

Different systems have different constraints. For example, loading the firmware interface on my systems so it can present a boot menu is way, way slower than rEFInd or Grub. And presents an ugly menu in a non-native resolution for my monitors. And doesn't let me override kernel parameters adhocly at boot time if needed (thought it has been a number of years since I have, I'm reluctant to let go of the option).

Pop!Os uses systemd-boot (formerly gummi-boot) by default if you're on an UEFI system, and only falls back to GRUB for legacy bios.

Arch is also much easier to setup on systemd-boot.

The issue is that GRUB still has a very compelling support matrix - it'll work basically everywhere, and with most all configurations. So if you're already running a batteries included distro, where someone else is doing most of the configuration and the downstream systems are hugely variable (old consumer hardware) - then GRUB still makes the most sense.

ExFAT can support those. You could also use the UDF file system.

> I would rather use Ext4 everywhere for everything. Is the problem preventing wide adoption of Ext4 GPL?

The BSDs don't support ext{2,3,4} particularly well, and Linux doesn't support FFS/UFS particularly well. I mean, there's support for these things, but it's far from complete or perfect and it's taken a long time.

It's just a fair amount of effort to implement filesystems well, and there's very little tolerance for errors. Ext4 isn't spectacularly complicated, but it's not exactly a simple FS either. I think that has more to do with lack of support than anything else: lots of effort for not all that much practical benefit.

And ext has plenty of documentation and they haven't implemented that either.

So I think keeping down the software complexity is the more likely method. Down to

1. The limited software investment these companies make (often just buying and reskinning firmware from AMI)

2. The limited space available on the ROMs due to hardware cost savings (e.g. companies have had to drop GUIs or support for less popular APUs to add support for new generations of mainstream CPU in firmware updates)

Although very complex and very undocumented, NTFS has actually been adopted very widely and quite reliably. Most of the pre-smart TVs and set-top-boxes can read FAT and NTFS USB drives which makes NTFS the only choice if you want movies exceeding 4 GiBs.