Yes, it would be nice to manage efi vars.
To the rest of your comment, yes grub2 is still relevant because it is still used, even in EFI environments. Having a boot menu in addition to your firmware can be neat, as firmware usually boots one option always unless you do X, or not present a menu at all. But then something like reFind works as a menu fine too.
Exactly this, I have a 10yo computer running Haiku + Linux and I never had to use rEFInd nor GRUB.
Most (all?) EFi boot loaders have their own OS selection menu (on my computer accessible by pressing F12 at boot) so I do not quite understand previous discussions (except if you are booting in legacy/BIOS mode)?
Not every EFI firmware allows you to select a bootloader. And this requires you have properly configured your efi vars, where reFind can autodetect efi loaders (and you can e.g âjustâ drop in memtest)
A bit offtopic, but just to be correct:
Linux kernel always was and will be elf executable. On the other hand, Grub EFI is efi executable. When you say âLinux⌠is able to boot from UEFI without grubâ this actually mean: âLinux kernel is loaded by Grub, which is loaded by EFI firmwareâ. Of course, Grub can hide its menu and timeout, but in booting Linux kernel, it is always present (or some other bootloader, LILO, Syslinux, etc).
Well, my statement is still correct. Linux kernel is able to boot from UEFI without grub. Does it need a first stage efi executable? of course, as Haiku does. But that can not be compared with a scriptable multi-os loader as grub, imho.
But we donât need grub, Linux does not need grub. Also, grub concept is almost against UEFI design. I would say grub is still popular because it already ships with Microsoftâs secure boot certificate, which makes it handy on live-usbs.
Linux supports beeing compiled as a âefiistubâ loader as they call it, negating the need for a secondary efi loader.
You can also put your initramfs into the kernel image to have a self contained linux image for efi 
Interesting, I feel like I have leant so much about the booting process in this thread, not least that the âboot managerâ is not really needed anyway. But does GNU GRUB play a similar role in getting GNU / HURD to work? HURD means Hurd of Unix Replacing Daemons and this implies a lot of moving parts to marshal. Also when playing wiht Genode (another microkernel system like HURD) the bootable image includes a GRUB partition plus another Bios one making three partitions in the image, so I think they might be relying on GRUB to do some lifting behind the scenes.
From the above I intuit that if we were starting out to do it all today from scratch Haiku would probably have adapted GRUB2 to our purposes, but since we are not, Haikuâs bootloader and its UEFIBOOT partition works for me, so canât complain.
No. Unlike Haiku and Windows, Linux kernel need very little preparation for booting. For Linux loading it into memory and providing ACPI/FDT is enough to boot. Linux kernel contains special stage that do logic similar to Haiku boot loader.
I looked around for a couple minutes to see where Hurd is these days. It wasnât clear to me that people are even putting it on hardware (as opposed to running on an emulator), but it was my impression that EFI isnât trivial for those few. Somewhat similar situation with NetBSD - lots more installed systems, but multi-boot is relatively rare, and ordinarily thatâs done with Intel partitions and BIOS loading. And similarly, the hardware could be a few years old. I wouldnât say the boot manager isnât needed any more. I managed to get 3 OSes all installed and usable on UEFI, but it was kind of a pain.
GNU/HURD ainât a Linux
Except Grub concept was present before UEFI was designed. I would say, UEFI was designed to (at some extent) replace third-party bootloaders like Grub. But yes, having UEFI capability to choose what to boot, Grub seems of less interest.