Fedora has a feature, “GRUB hidden menu”. At boot time GRUB resets a counter in a file called grubenv and if the boot succeeds, a systemd unit updates this counter to indicate success. The next time GRUB reads this file, it knows whether the boot was successful. If it is, the GRUB menu isn’t shown, the counter reset, and the system booted. If the boot wasn’t successful, the GRUB menu is shown, and the counter reset.
The gotcha is if this file is located at /boot/grub2/grubenv, as it is on non-UEFI systems. If /boot is on Btrfs, then GRUB writing to grubenv becomes indistinguishable to Btrfs from corruption because the write isn’t happening through Linux kernel code - the various parts of Btrfs metadata including checksums aren’t updated. Because of this, writes to grubenv are disallowed by GRUB when it detects the grubenv file is on Btrfs. This also applies to mdadm RAID, and LUKS. If the boot success counter can’t be reset, GRUB always thinks boot succeeded, so it never shows the GRUB menu.
There are some ideas how to resolve this, but they’re not likely to happen in the Fedora 34 time frame. So I expect /boot will remain on ext4 by default; but the installer will let you do this in Custom and Advanced-Custom partitioning. You can still show the GRUB menu using F8, which on a number of systems requires also pressing an Fn key.
As for the future, I expect we’d have a quick doc describing how to migrate $BOOT to Btrfs. And users can decide if they want to do that or do a clean install.
It’s true for Btrfs on LUKS, $BOOT needs to be unencrypted. But once native Btrfs encryption lands, it’ll be possible to selectively encrypt (or not) each subvolume. So the subvolume used for $BOOT can be non-encrypted.