I'm not sure why they insist on installing GRUB when UEFI allows the firmware itself to act as a boot manager (remembering boot options and their order) and the kernel itself can be booted directly as an EFI application.
Well first of all the goal is that there would be no debugging required if the system works well, and in my opinion less moving parts (like GRUB) means less chance that something breaks.
The UEFI boot entries can be configured by the operating system with the "efibootmgr" command (http://manpages.ubuntu.com/manpages/bionic/man8/efibootmgr.8...) so if a more user-friendly version of it is required then a GUI can be written around that. Whether it's necessary or not is another matter because as far as I know there is no GUI around the GRUB configuration either and it mostly works.
Speaking of GRUB, how it works in Ubuntu land is that there are a couple of scripts that read different configuration files to generate the final GRUB configuration file which is actually a bash-like script (yes, GRUB implements a scripting language) and if you look at it you'd be horrified. The UEFI way of doing things is much simpler.
So the idea would be to 1) check whether the installer is booted in UEFI or BIOS, if UEFI then check if an existing OS is installed and whether it boots in BIOS or UEFI mode (whether the drive is partitioned in MBR or GPT), and then decide whether to skip GRUB (for UEFI-capable configurations) or keep it (for BIOS systems).
grub with timeout 0 achieves the same visual effect, but sometimes you need debugging (windows also has "boot into safemode, android has recovery etc.).
There are many bootloaders you could choose from efistub (which you mention), gummiboot, refind ... . Having one with a user visible interface is useful if you either dualboot or want to expose things like previous kernels or filesystem snapshots.
> So the idea would be
Sure you could do that, or you could set grub timeout to zero if multi booting, larger timeout if not and present the same familiar interface no matter whether you use UEFI or BIOS.
My argument was less about the visual impact and more about having yet another moving part. A timeout of zero doesn’t magically solve the complexity of its configuration or failure modes.
systemd-boot is a good solution to this problem. It's less of a horrible complicated mess than GRUB. You can add menu entries for multiple operating systems, an EFI shell, and the BIOS menu, just like with GRUB. It has a much nicer configuration story and integrates with the other systemd components (so, for example, you can reboot into a different boot menu option through a systemctl reboot flag just like the equivalent feature in Windows).
systemd-boot only supports UEFI systems, so GRUB would still have to be an option for legacy systems.
I kind of wanted to mention it as what I think is a better alternative but I feared it would label me as a systemd propagandist (given the polarising nature of it, even though personally I think it’s advantages outweigh the - often philosophical - drawbacks).
I think that anyone can recognize it as a good alternative for Ubuntu, since Ubuntu already uses systemd (and that's a done deal).
I'd consider myself a pragmatist, so I like systemd because it makes my life easier with the declarative configuration and other nice features (although I recognize that it makes some people's lives harder).