OK, so to clarify, I know it's possible to boot Windows from a logical partition, I've did it before. And even though I've specified W10, it's only because that is what I use and is the only Windows that my hardware officially supports, this issue really can apply to any recent-ish Windows version.
But anyway, I have a 3 disk setup, 2 are MBR, the 3rd is GPT (it's not over 2TB, but I am testing OS X and FreeBSD, the most recent versions of those OSes prefer UEFI/GPT). The first 2 are SSDs and contain Windows/Linuxes as OSes. The 3rd is an HDD and contains 2 OSes, but is mostly non-boot able data partitions (i.e. /home partitions for Linuxes, games, etc).
I prefer to boot Windows and the Linuxes on legacy MBR, since it compatible with more tools, bootloaders, etc. So, to anyone that wants to suggest that I just install Windows as UEFI.....no. Don't bother.
The biggest issue with MBR is the partition limit, either 3 primaries and an extended containing logicals, or just 4 primaries. My setup must include an extended because of the # of separate compartmentalized partitions I have a need for. I'm finding myself squeezing as many partitions into logicals as possible, reserving the other primaries only for the purposes they are really needed for. I'm just trying to partition smartly and make the most optimized use of MBR's partitioning requirement. I figure if I can force Windows to live in a logical without issues, that is one more primary slot freed up.
We all know that Windows preferred to be installed on a primary. But this is just a stupid artificial MS thing that they insist on. It is not necessary, Linux lives perfectly happily on logicals, even a separate boot partition doesnt need to be primary, as long as the boot code can find it, it doesn't care.
I can chainload the W10 logical from GRUBDOS, no issue. But since Windows wants its' volume to be active/bootable, and it currently isnt, I can't do things like hibernate, updates, msconfig/diskpart shows the W10 partition is a boot volume but not a system volume. Of course, easiest way is to let 10 have its' primary, then C drive will be both the system/boot/active volume. Or, 10 (the OS files) on a logical as the boot volume, and the boot files on a small primary System Reserved. But the SR partition is so small, I do not feel it is deserving of a primary slot, not when I am booting lots of alternative OSes.
Then there is the possible issue of my encryption solution not being happy about there being a boot volume but no system volume.
I can use dism/imagex to install the OS, and then bcdboot to install boot files to the same logical. Then I can mark it as active with GParted, which doesn't have diskpart's limitation of a logical not being able to be marked as bootable. But I am not sure if Windows will fully function with this arrangement. Does the setup I want have any other potential downsides I should know about (things that won't work)?. Or, is there a better way to approach this that I'm missing (boot files in a VHD, WIM, ramdisk partition, etc)? I may consider UEFI on MBR, or hybrid MBR, but those will be considered last. UEFI on MBR works fine on my firmware, not sure about hybrid MBR since I have never tried it. want to run lots of tests in a VM to try out different scenarios before I commit to anything.
And...an unrelated question:
Is it possible to chainload a UEFI bootloader, without rebooting, from a legacy bootloader like G4D? Or vice versa? If not, why? And without UEFI emulation such as Clover or vice versa? It doesn't kill me to hit F7 at boot to select the GPT disk, but it's an extra step.
Edit: Oh, one more thing, I'm not running Apple hardware. It is a Sager gaming laptop, with OS X installed from a official Apple Store DMG converted to bootable ISO, with the install media booted from an iODD. I just had to install some kernel extensions, NVIDIA driver, and the Clover bootloader to get it working. Disk is standard GPT created from GParted, with a FAT32 EFI system partition shared with FreeBSD. Just wanted to be sure that people don't think I'm using Apple hardware.