The issue results from grubenv being located on a Btrfs “boot” volume at /boot/grub2/grubenv which is not a default configuration, but is permitted by the installer. The consequence is GRUB pre-boot environment cannot modify grubenv, the single example where it does so is resetting boot_success to a value of 0 so that GRUB knows whether to show the GRUB menu or hide it as a result of another environment variable menu_auto_hide=1
If GRUB sees that boot_success=0 then it’s assumed the boot was not successful, so it shows the GRUB menu. If it’s 1 then it assumes the boot was successful and the menu is not shown, but it also changes the value to 0 so that it’s reset in case the boot fails, it’s ready to show the menu the next time around. Since it can’t be changed when on Btrfs (or ZFS or dmcrypt or mdadm raid or LVM), autohide is always true because the reset to 0 never happens. So one work around, if you’re customizing /boot to be Btrfs anyway, is to disable autohide.
grub2-editenv - unset menu_auto_hide
Of course, dual booters always see the menu, since there’s code in the grub.cfg that detects multiboot setups and always shows the GRUB menu in that case.
NOTE: The reason GRUB pre-boot can’t change grubenv on Btrfs is because it doesn’t write via a file system driver that knows how to properly update all relevant Btrfs metadata, GRUB just overwrites the sectors containing the grubenv contents with new value(s). And Btrfs sees this as corruption because it checksums everything, including the grubenv file. There is a non-upstreamed patched by SUSE that stuffs the grubenv into the bootloader pad, which on Btrfs is quite significant in size and is an area that the bootloader can exclusively use reliably - it’s an area that isn’t subject to btrfs check/scrub/balance and isn’t observable or modifiable from the file system. It could be an option to bring this into Fedora.