I like to preserve the ability for the user to boot to the original Windows they have become familiar with, so they will have continued access to their local files using established permissions, apps, bitlocker, etc. Going forward on their own time at their leisure.

Shrink that old NTFS volume quite a bit, which the user won't be using that much more anyway, and make a new NTFS partition for W11. Pay attention to the usual optimizations like no hibernation or auto Daylight Savings adjustment and nothing beats dual booting the regular NT6 way. I also disable bitlocker for the Windows install process once that became the default, this must be carefully reserved for intentional deployment with the user's involvement afterward. Then in remaining space on a third major partition, install Linux to a single dedicated EXT-formatted type {0FC63DAF-8483-4772-8E79-3D69D8477DE4} volume.

Usr, swap, home, etc will all be there in one place (not unlike Windows which most often is confined to a single main partition itself, utilizing only the boot files located on a separate dedicated boot volume), and Grub will point to the still-existing functional NT6 bootloader when you need W10 or W11.

You create the new Linux {0FC63DAF-8483-4772-8E79-3D69D8477DE4} partition in Windows beforehand, which does a good job of alignment on SSDs, and leave the intended Linux partition unformatted. In Diskpart SET ID={0FC63DAF-8483-4772-8E79-3D69D8477DE4} to categorize a selected ordinary Windows OS partition as a blanket Linux partition instead, regardless of whether either one is formatted yet or not. Once the Windows system is OK (multiboot or not), then boot to the setup USB of the chosen Linux distro instead, and if everything is nominal the established boot volume will be autorecognized, you can choose the target unformatted space for your root, making no other choices for things like USR, Linux will install to that single target partition and it will just work. Linux goes onto its own partition, never touches Windows at all, nor anything in the \EFI\Microsoft folder. In this case Linux merely replaces the \EFI\Microsoft-seeking \EFI\BOOT\bootx64.efi, one single file (which you can "easily" back up once you gain access to the EFI folder :\), with an identically-named \EFI\BOOT\bootx64.efi which instead seeks a \EFI\ubuntu folder, for instance.

Where the \EFI\ubuntu folder is its own boootfolder autocreated during a ubuntu install process. Not much differently than the \EFI\Microsoft folder that was autocreated during the initial NT6 installation process. Where additional Windows versions installed later to other partitions do not create additional \EFI\Microsoft folders, but instead adds a bootmenu entry within, pointing to the newest Windows install as the new default. Leaving previous Windows installs as non-default entries.

You also may have to put adequate focus on the EFI subfolders on the SSD so they can handle the boot process completely, without any dependency on the actual UEFI firmware boot entries within the mainboard, but with some optimnized settings this just works too as soon as the Linux install is complete. Regardless it often may be best to delete the mainboard entries themselves once this is confirmed. But different mainboard UEFIs can have different approaches to the settings needed for this to work to your advantage. UEFI may be stupidly more complex than BIOS, but there are still not that many different settings compared to most user software and it doesn't take that much effort to become more familiar than the average person. After all this time has passed, the bar is still very low due to so many mainstream users recoiling in absolute learned fear at the thought of even looking at their BIOS settings. Not a problem for a true tech noob if they put their mind to it, but when does the average noob get around to that? I thought so.

In an ideal UEFI implementation proper firmware entries are autogenerated from what is found on the SSD. But sometimes only when there are no existing entries in the UEFI or anything else unexpected, and not often will unused entries be autoremoved properly once a particular SSD has been intentionally disconnected and is no longer part of the system. UEFI Shellx64.efi can be your friend which is like DOS only simpler, but few go there either. If you can do a hello world in any language you can probably remove unwanted entries with a UEFI shell though. Can also be accomplished from the command line in Linux or Windows but Shell is easier.

If you do get a wild hair and manually put back the original \EFI\Microsoft-seeking bootx64.efi file back into the \EFI\BOOT\ folder, to replace a Linux version of bootx64.efi, well the PC will again act like there in no Linux at all then. No sign of Grub will exist and Windows will naturally not natively see the files on the EXT volume.

Upon startup a Linux-seeking bootx64.efi proceeds to Grub in the \EFI\ubuntu folder, where Linux is the default but you can choose to (multi)boot Windows as the main alternate choice any time you are at the Grub bootmenu. Because Windows bootloader is detected and autoadded to the Grub bootmenu during Linux install from the beginning. Additional versions of Linux installed to further partitions will become the new default in Grub. To get Windows to be the default in Grub you have take action yourself though.

If you then install an additional Windows version, or re-install Windows in many nominal ways, it will usually overwrite the Linux-seeking bootx64.efi with a Windows-seeking version, and then it acts like there is no Linux any more either, but Linux is still there untouched assuming you always correctly direct any Windows or Linux installs to a single partition at most, without overwriting, formatting or deleting anything else, especially not re-partitioning of any kind.

This is all provided you have almost every single option on the Linux install routine very carefully chosen to achieve this exact scenario. Once you determine the settings it's a breeze to get there every time.

Unfortunately there can be a big difference between distros as to how to get the settings right so serious rehearsal using SSDs containing no valuable data is a must :\

When the time is right, any OS on the drive can have its ethernet & wifi devices disabled once it is no longer being effectively secured from network threats. So the user doesn't accidentally go on the web with an OS that they shouldn't.

Sure is a lot easier to just discard everything on the SSD, turn it over to Linux completely and kill 'em all, but it's not for everybody and some people do really well with a transition piece or two.