The article does not characterize the status quo as hacky, and furthermore does not acknowledge the existence of mainstream setups that do not share the pitfalls of the "typical setup". I.E. the article kind of creates a strawman.
In the article the Linux mount point can be as described regardless of where the Linux boot files & kernels are physically stored in the various partitions & folders. We see this variation in the wild observing the different physical locations among the different distributions.
Or you could put key files in places as yet undescribable. That's a worthwhile advantage for Linux, your choices are less limited.
With legacy BIOS doing the job, it's always been smooth & straightforward to use the DOS and/or NT boot loaders to choose between multiple Windows and Linux installations on different partitions. Even though only one out of a maximum of 4 primary MBR partitions per HDD are capable of being marked bootable at a time, you can still boot from there to as many logical MBR partitions, as you can GPT volumes under UEFI. Either way HDD space is the only limitation, UEFI offers no advantage here; when Microsoft orignally claimed it did they were obviously lying.
As it stands now, the Microsoft UEFI boot loader will still not boot Linux, so it is not yet as advanced as the Microsoft BIOS boot loader was 20 years ago.
Therefore to multiboot Windows and Linux by UEFI, you now need to use a Linux boot loader for Windows, when you never needed to do that before, and that basically means Grub2.
Too bad Syslinux 6.04 was badly fragmented in its misguided rush to attempt UEFI without deep co-operation with the actual Syslinux Project itself. So the various 6.04's are somewhat of a shitshow even though there are some nice features that hopefully will condense into stability someday when UEFI becomes truly well-handled. One can only hope.
Syslinux 6.03 has been highly stable and very feature complete since 2014 and no urgent work should be expected, but that is only for FAT32 BIOS booting not UEFI. Along with Isolinux of course for CD/DVD booting, and Pxelinux for netbooting.
Anyway Grub2 has some forks that will read Syslinux config files if desired. This can be good if you want to stick with the tradition of manually creating and editing your own text config file from better documented references the Syslinux and Grub1 way. Compared to the Grub2 approach which highly discourages touching the config file and autogenerates it occasionally instead in a somewhat mysterious way which is much more poorly documented.
But the stable Grub2 is just fine with its own kind of config file, and now works great on UEFI for multibooting Windows.
Anyway, when Windows 7 first appeared the HDD was still structured with a single NTFS partition spanning the whole HDD, with a boot loader file in the root of the volume along with a BOOT folder containing the BCD, just like Vista. XP has a couple boot files and BOOT.INI in the root with no need for a separate boot folder.
So the boot files and folders were in the same drive volume that the Windows folder was installed to up until that point but this was never a required layout. This was recognized by multibooters since additional Windows installations made to different partitions required no additional boot loaders of their own. Further Windows installations to the same PC simply add an additional boot entry to the default bootmenu in the Windows config file (BOOT.INI or BCD), triggering the menu to display upon startup when there is more than one entry.
A number of months after the first release of Windows 7, the boot files & folder disappeared from the Windows volume and began to be located in a small (often 100MB) hidden FAT32 first partition preceding the following second NTFS partition spanning the remainder of the HDD. Although OEM layouts often had third or fourth partitions somewhat hidden following the main Windows volume for built-in recovery and/or restoration, when you installed Windows from scratch you would not have these low-GB final partitions unless you took the effort yourself.
Or in my case leave some large final partitions for various NTFS, EXTx and FAT32 formatting later.
All you ever do then is add entries to an already functional bootmenu in a hidden volume.
Plain to see. /s
Not enough people saw it, but this was when there was finally way more space on the HDD than Windows needed, leaving plenty for Linux. Or other Windows versions, VMs will only get you so far. Judicious partitioning was as good or better than having a second HDD dedicated to Linux.
PC started out with a Windows bootloader/bootmenu and with MBR/BIOS you can just add enties to boot Linuxes which are installed onto their EXTx partitions if you wanted. Or you could switch to Grub on the hidden volume and accomplish the same thing, or Syslinux since it was FAT32.
But a regular Windows PC would boot to a Linux partition(s) from its original Windows bootmenu, and you had complete manual control of the config file from Windows (or Linux).
Once the UEFI system descended from this structure to depend on a similar but more obscure FAT32 ESP volume containing boot files, preferably the first partition on the HDD, it cemented the sensibilty to continue adding new boot entries to the default structure, rather than restructure, except in very particular situations.
Well, no, you don't chain-load Windows from grub either because then PCR are wrong and Bit Locker rightly complains.
Which is why you... Just use the system boot manager to pick which loader to load. Easy, problem solved.
And you can edit the system boot manager entries from Linux and Windows, set bootnext from either one. It's really strictly superior to what you're describing.
