a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it.

b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.)

c. Change the release criterion.
 https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dual_boot

Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora.

Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora.

d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release.

I've been to numerous events where we helped students install Fedora into dual boot. One of the top 5 questions afterwards (maybe even #1) is "how do I make it boot Windows by default?". In the old days, that consisted of editing the grub config file and changing the default selected value to match the Windows boot item, or when "GRUB_DEFAULT=saved" actually worked, I just told them "It will remember the last selected option". That was easy enough and user friendly.

From the proposed options, only a) satisfies that. It is a bit inconvenient that it adds a few more seconds to the boot process (one more reboot), but it can boot Windows by default. If I told them that they must boot Fedora and select something in some menu every time they want to boot Windows (option b)), that would be a gameover. Many of them wouldn't have wanted to install Fedora in such a case. Especially for newcomers, Fedora is just an experiment, a **secondary** option. If we can't deliver that, if we "hijack" their computer and make Fedora the primary system, and make it hard to get into Windows (which they intend to continue using 90% of their time), they'll not want it.

I know that there are other approaches available, like the firmware-based one-time boot menu invoked directly during system startup. But again, for newcomers, if I tell them "the PC will boot Fedora by default, and if you want Windows, you have to press F12 during startup and choose Windows", many of them will not want it. The other way round (boot Windows by default, press F12 to boot Fedora) might be acceptable for them -- this is easy to achieve for power users using efibootmgr after installation, but if Anaconda included such a configuration option, it would be accessible even for less experienced users. There are still issues with this approach, though:

1. I'm not sure if all systems actually support a one-time boot menu.

2. The one-time boot menu key is different on different systems, and it's mostly not advertised during startup, and so you have to figure it out by trial and error (or from a system manual) and remember it.

3. And some systems are configured for a "quick boot" where they actually ignore keyboard input during startup and you can only enter it by using a tool from a booted OS (efibootmgr or a Windows alternative, some Rescue dialog hidden deep in system settings).

While all of us here are happy to run Fedora by default, let's not forget about newcomers and their needs, because our user base will die out otherwise.

So, in the ideal world, a combination of approaches would be accessible. Option a) to support booting Windows by default (or Fedora, or whatever you picked last), and also a userspace graphical utility which would allow users to set the Windows bootloader as default, therefore saving some seconds on each boot. Of course it would include a guide on how to figure out and test the one-time boot menu first, and allow them to change the default bootloader back to Fedora if they wish.

If there's not enough will to implement option a) (or some workaround with the same effect), we'll have to change our release criterion (option c) - I'd probably propose some changes to the wording). I don't see any benefit in delaying the status quo (option d)). But we should also clarify the situation to our users. On the Fedora download page, we should make it clear that users with an encrypted drive will not be able to boot Windows out of the box anymore, and they'll need to take additional steps to get into Windows. That might include a tool in Fedora (option b)), or figuring out how to get to a one-time boot menu. It should also contain instructions on how to switch back to the Windows bootloader by default (after installation, and ideally also as an option during installation), and how to boot Fedora then.

A note: Option b) mentions the Windows boot menu would get removed on UEFI systems - it would be good to do this only if anaconda detects a Bitlocker partition. There's no need to make it harder for Windows users who do not have their disks encrypted.

Thoughts?