Good to get your message.
>Normal people probably don't want to deal with this
Guilty as charged, I've rarely been accused of being mainstream anyway ;)
People should keep in mind, on a regular HDD or SSD if it just has a bunch of partitions but no boot files, it's acting no differently for storing folders & files whether the folders contain nothing but video MP4s on one partition, or an OS actually installed into folders on another partition.
Each of the partitions that do have a (different) OS properly installed, perhaps using different filesystems, can stand alone after booting, and can be booted from boot files located on completely separate media if desired. Not much differently than using a boot floppy to start W9x when the install was perfectly intact but only the boot files had become corrupt.
One of the simplest logical approaches is to have two HDDs, but only put one in the desktop at a time to install each OS completely independently. That's how I got started, for some reason I was trying to make it foolproof, just for me ;)
You can also make duplicate HDDs to stand by as backups in case of hardware failure, data corruption, or misconfiguration.
There's a great deal of confidence when you know you can slap in a known working HDD no differently than a proven replacement "hardware" component, and it does the one thing it is supposed to do.
It's a slippery slope, the next thing you know you end up with both HDDs in the same PC, and not wanting to touch the arcane but mysteriously functional boot files on each HDD, you instead use the BIOS to select which HDD you boot to upon startup. If you want something other than the default.
From that point with no further editing of either HDD, you also have the option of using a third bootable item instead containing only boot files itself, whenever you want. Floppies used to be big enough, CDs were a pain with no editing, but USB sticks do the trick now. This is where the "hello world" of multiboot configuration can be confined to, and if it turns out to be more confusing than expected (this is by design) it can actually be perfected at your own leisure in case a single session is not adequate.
If you're not careful you'll end up treating different partitions on the same SSD as if they were completely different SSDs, almost like it was logically intended ;)
And your boot files can be just about anywhere, even in more than one place at the same time, but you only utilize a single path each time like anyone else.
Ideally, after you're successfully using a USB stick containing all the boot files necessary to multiboot a particular partitioning structure, that would be the equivalent of what was needed in a dedicated boot partition on a single SSD to accomplish the same thing. Further, you could actually have an equivalent boot partition on each SSD that all do the same thing, whichever one happens to be the active boot device at the time. You've got to pick a preferred device for the motherboard to boot to anyway if it's not the exact one the UEFI is defaulting to.
With UEFI I sometimes use an approach where I have two FAT32 volumes, one at the beginning of the SSD and the other at the end. The first one is the factory ESP volume whose contents don't need to change if all you want is Windows. The second FAT volume contains a slightly different EFI folder that can multiboot to the same Windows as well as the Linux install. Change the GUID of the original ESP partition into "Basic" instead of ESP, then rename its EFI folder to something like EFIorig. After formatting the second FAT32 volume, you assign it the proper ESP GUID then first populate with an EFI folder using Windows' bcdboot.exe. A following proper Linux install into an existing available partition will add the Linux boot option to the new Windows EFI folder on the second FAT volume. Leaving the original (but renamed) EFI folder untouched in the first FAT partition. By selective renaming you only have one folder actually named "EFI" at any one time, and you may or may not need to assign corresponding ESP GUIDs depending on which FAT volume you want UEFI to proceed with. Lots of UEFI firmware doesn't need an ESP GUID for guidance, or even a GPT layout, the good stuff can access all FAT volumes on either GPT or MBR layout, locate the first valid EFI folder on one of them and go forward from there.
For Secureboot I like the distros that rely only on Microsoft-signed keys that are expected to be built in to each motherboard at all times, I do not want to do anything that would mess with the mainstream Windows machine keys, or require Linux keys to be installed into the firmware before it will boot Linux. For those distros I just disable the false sense of secure booting when using them, fondly remembering that Microsoft Secure Boot was originally possible to be toggled in UEFI under the nomenclature of "Windows 8 Feature".
Like all of the other Windows 8.0 "features" that people everywhere loved so much more than Windows 7 could ever achieve ;)