One problem with sd-boot is that the kernels must stay on the ESP, which can be a problem for dual-boot installs (where Fedora has to run with the existing ESP and can't just create one which is big enouth).
Nah, that's not true. Hasn't been for quite a while.
sd-boot checks for kernels in the ESP first, and then on a second partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR partition is simply a partition with type UUID bc13c2ff-59e6-4262-a352-b275fd6f7172.
Ah, this is news to me. XBOOTLDR must be formated with a filesystem the uefi firmware can read (i.e. vfat in practice) I assume?
Another problem is that grub2 covers more architectures than sd-boot. What is the plan for armhfp, ppc64, s390x?
sd-boot is uefi only, but it should work fine with any arch that is supported by uefi.
Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi doesn't exist ...).
IMHO a better preparation for deprecating BIOS would be to make new installs bootable with both BIOS and UEFI. Which isn't hard at least for the "[x] use all space" case where Fedora can partition the disk as it pleases: Use gpt. Create a bios boot partition, install grun-pc there. Create a ESP partition, install grub-efi there. Create a partition for the /boot filesystem. Have both grubs pick up BLS config from /boot/loader.
My suggestion would be: don't standardize on boot loaders, standardize on the boot loader spec.
Using the above partition scheme probably works with sd-boot (instead of grub-efi) too if you tag /boot as XBOOTLDR.
The point I was tring to make is that you can install fedora in a way that the disk can be booted in both bios and uefi mode.
take care, Gerd