tl;dr --first sentence & footnote only

Multibooting is definitely the way to go, it could be seen 20 years ago when drive space began to outpace size needs of Windows' C: volume under typical user conditions.

Every Windows PC eventually was going to have enough drive space for more than one OS, in the long run (now) room for many more.

And the hardware was going to boot so fast, there was going to be no reason not to just quickly and simply reboot to Linux for the internet, or Windows for office work or gaming.

But you have to be able to teach multibooting, and for that you have to practice it yourself reliably.

Well, I'm here to say there are advanced geeks who are still just as bad at multibooting as below-average Windows users are at Linux.

So Linux is still not flying off the shelf even though it's free, and can be added to Windows PC's without Windows users losing anything.

For years now.

The hardware was made for this since the beginning (using multiple floppies, then later multiple HDDs) but it could be considered a manual operation.

Later DOS versions supported the IBM concept of partitioning a single HDD into a maximum of 4 primary partitions, analogous to a 4-drawer filing cabinet being replaced by a digital alternative. A folder(s) containing an OS can safely be stored in any drawer no differently than any other folder. Windows iconized DOS directories as folders as time went on.

The BIOS (later a biosmenu) chooses which HDD to boot to in the original way, then further boot (menu) sectors/files on the HDD choose a partition having a folder containing an OS, then any OS treats each partition equivalently to a separate _drive_ of its own.

This part of the process wasn't even that slow when PC's were 1/10 the speed.

And Windows responded by salvos of bloat with each revision, sometimes in separate inter-revision events where much larger amounts of downloaded material was retained by huge leaps over what the originally issued OS started out doing, as drive space made excellent leaps in affordable space for users, the excellence was nullified. In my estimation a most Ballmerish occurrence.

Also the original NT6 Vista & Windows 7 versions started out with the BOOT folder right there in the C: volume where the default bootmenu it contains could conceivably be edited easier (easier than it was later when hidden in a separate unexpected partition).

Except for the NT6 boot files which became more arcane by orders of magnitude, this is by design.

You need sufficient BCDEDIT skillz at the administrative command line to modify your default NT6 bootmenu, but you only needed a text editor for the human-readable BOOT.INI of NT3-5 or CONFIG.SYS in W9x.

And with NT5 (or NT6 using BIOS/MBR) you could still boot (multiple) Linux(s) from the regular Windows bootmenu, but no Linux for you with NT6 bootmenu in UEFI, this is by design.

No overcoming Windows SecureBoot obstacles in UEFI for Linux either until earlier this year in 2020, this only set Linux back 6 years when it comes to brand-new PC's.

And all you have to do is learn how to multiboot well enough so you only have to teach people how to use a boot menu(s) in the way that everyone should have already been using now for decades.[0]

Now in a FAT32 ESP with UEFI/GPT, Linux installers put their boot files alongside Microsoft's in the generic shared EFI folder, while the Linux OS itself can be completely directed to a single unused partition, /home /var /usr everything on a single type 83 EXTx volume. Without touching Windows on its established NTFS partition. It works so well, it's the closest thing to Linux on a Windows partition.

Windows can make the partition and Linux can do the rest.

Then you have two completely different formatted partitions each containing their native OS, and the original common FAT32 ESP containing the key EFI folder now having both OS's boot files in their own subfolders.

And the proper Linux install just leaves your mainboard with a new UEFI top-priority firmware bootentry pointing to the new Linux bootfiles in their EFI subfolder, pushing the established firmware bootentry for Windows down the list in the mainboard UEFI.

This is after the Linux setup process autofinds and autoadds the Windows install already present on its NTFS volume to the new grub menu so you can choose original Windows or new Linux while the UEFI is set to select the new Linux subfolder within /EFI.

You can always set the mainboard UEFI back to boot to the unchanged established Microsoft UEFI bootentry instead of the new Linux UEFI bootentry, and the PC will act like Linux is not there at all, the new grub bootmenu will not appear and Windows will not normally be able to see or access the Linux partition. You could also use a built-in mainboard firmware bootmenu to manually choose between Windows or Linux during bootup, not much differently than if they were on separate HDDs, without needing any grub access to Windows, but not every UEFI mainboard even has a built-in bootmenu any more like BIOS did (BIOS could only choose from different HDDs, not the individual OS's on the HDDs like UEFI sometimes can do in addition), and they are all different but can be useful when there.

______________

[0] If a real programmer is interested, what is still missing is a new standard open-source UEFI bootmenu firmware executable.

User-configurable to allow flexibly selecting which mainboard UEFI entries appear on its own menu when called, and their boot priority.

And as simple as possible, to be unchanged afterward, we already have overly complex grub & Windows OS bootloaders downstream on the HDD, as moving targets.

We just need a new hypervisory bootmenu upstream, to run under UEFI before booting an OS or its particular bootfiles, so there will be a standard way to select from firmware bootentries themselves. Without having to properly access the (otherwise confusing but potentially simple) UEFI boot choices manually while booting, using increasingly divergent mainboard Setup routines as more years go by.

In the form of a small .efi executable to be placed on the ESP volume, which can be called from the startup.nsh batch textfile (also store startup.nsh on the ESP volume).

While still being able to eventually obtain Microsoft SecureBoot signatures to any extent needed for such a useful bootmenu.efi & startup.nsh to come into simple routine use.

Which if present, a startup.nsh file is already the thing addressed by UEFI before the mainboard ratchets down to booting the top-priority bootentry in its own UEFI list instead, and startup.nsh is a userfile so we would best start using it.

But nobody's using startup.nsh yet, it's still not significantly underway for over 6 years now.

It's just another obstacle where the resulting UEFI mainboard boot-performance landscape is ridiculously unstandard (and getting worse) by comparison to the previous BIOS approach which was never a formally published standard at all, and BIOS got better over the years.

That's damage from a big UEFI foisting salvo by design, fully forseen.

And Microsoft SecureBoot still looms large as a related obstacle from 2014 since they have not yet signed an open-source UEFI Shell for SecureBoot operation either. Shouldn't be essential for developing a .efi executable bootmenu program anyway, but still a bad lingering deficiency in simple UEFI utilities, and confirms Ballmer's ghost still haunts regardless of WSL or what anyone says otherwise.