I like to have each Linux distro on a standard type 83 partition if in BIOS mode, or its corresponding 0FC63DAF-8483-4772-8E79-3D69D8477DE4 GUID if in UEFI.
These are neutral dedicated storage designations for later EXTx formatting.
With Windows to be on partitions of BIOS type 07 or UEFI GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7.
Once again neutral dedicated storage designations, for later NTFS formatting.
Each distro is entirely self-contained on its own single volume, no separate /usr /home swap or anything else.
This is analogous to a Windows install.
But as intended, bootfiles can function properly from many different storage locations.
In BIOS you will need boot files on a primary partition and it will need to be the primary which is marked "active" (bootflag 80 rather than inactive default 00). You will also only be allowed to have a maximum of 4 primary partitions in BIOS. But with correct bootfiles on an active partition you can boot to OS's that are on logical partitions too if you want to put them on your bootmenu.
In BIOS you can have a /boot folder on the same primary that your distro is on and it can boot solely to the distro on that primary (no boot menu appears), or you can have more than one bootentry on the GRUB or Extlinux bootmenu, which triggers the bootmenu to appear and then you can boot to any other partition on the menu whether primary or not.
Analogous to Windows in BIOS when the BOOT folder is on the same active NTFS volume as the OS folders. In BIOS Windows will boot Linux using a BOOTMGR entry pointing to a copy of the Linux volume bootsector, stored on the NTFS (or FAT as often seen when a commonly found "hidden" partition1 is used for Windows bootfiles) filesystem in the form of a file.
Windows will not address files on type 83 or 0FC63DAF-8483-4772-8E79-3D69D8477DE4 volumes so they are hidden from Windows naturally without having to possess the hidden attribute. These partitions will be sensibly handled in diskmanagement, 0FC63DAF-8483-4772-8E79-3D69D8477DE4 will show as OEM rather than a blank table entry.
Linux can mount FAT (FAT32's preferred type is usually type 0C) or NTFS whether it is marked hidden or not. Type 1C is hidden FAT32, type 17 hidden NTFS. In BIOS Linux can boot Windows if you want to put it on your GRUB bootmenu.
It can be seen that you could have 4 primary partitions, each containing an independent Linux or Windows OS, with 4 specific boot folders, one dedicated to each OS on the same volume the OS is on. Whichever one of these partitions you designate with the bootflag will be the one that boots, and the other partitions if unhidden can then be mounted as ordinary storage volumes. You would never see a bootmenu and would have to change which primary has the bootflag in order to choose which OS to boot to.
This is good when you need to boot to something different and do a comprehensive backup of a working volume but in its static dormant state, whether bitwise or file-based backup.
Sometimes there are no spooks trying to cause mayhem, and the most reliable rapid backup & recovery methods need to be constantly rehearsed and revalidated foremost.
However, in any one (or more) of these BOOT folders on any of the primaries you can trigger the display of its multiboot menu simply by adding a second (or more) bootentry of your choice to its default boot configuration file.
You could even have identical full multiboot menus in identical BOOT folders on each volume, and even on an external bootable USB volume too.
This gets analogous to UEFI where you only use one /EFI/BOOT folder on a special C12A7328-F81F-11D2-BA4B-00A0C93EC93B GUID ESP partition (but if not found then the first FAT volume the firmware recognizes), formatted FAT32 and readable by all.
But in the EFI\BOOT folder there is just a .EFI file or 3 (like BOOTX64.EFI) which is what each OS install strategically renames its EFI bootfile as, which then points to its own specific \EFI\Microsoft or \EFI\debian ect. subfolder which takes it from there. The Microsoft subfolder will contain its bootmenu, better Linux distributions have it this way too (ie you can edit its GRUB bootmenu when booted to Windows because you can see it in the desired EFI\Linux subfolder), but some distros only link (during bootup) from their subfolder to their bootfiles on their EXT partition and can only be edited when booted to Linux.
Now in UEFI I have not found a way to get Windows bootmenu to boot Linux. There should be a BCDEDIT switch that should do this like there is with BIOS BOOTMGR. If Microsoft starts to get serious about interfacing Linux this would be the first deficiency they will correct, so we will know if that occurs.
It can be seen that Microsoft SecureBoot was developed in quite a stifling way when it comes to Linux. For instance if you need a live Linux distro to be bootable on any default PC which has Microsoft SecureBoot enabled, you definitely need to have a Microsoft-signed shim or something like that. Machine owner keys are good for all the top-secret operators and serious geeks but ordinary power users want things like that to just work with the same default Microsoft-signed key that Windows uses without having to insert custom keys into the mainboard firmware. The only key that's built into every modern PC is signed by Microsoft, simply because it's a PC not a MAC.
Often the Microsoft-signed Linux SecureBoot shim will be renamed to BOOTX64.EFI which is what the firmware is looking for and from there the next bootfiles are signed by the distro.
The problem is that not every Linux distro uses the same key/signature so there are some different shims, one from each major distro that overcame the SecureBoot obstacle by having a shim signed by Microsoft.
This really makes UEFI highly defective when it comes to running live distros or multibooting, compared to how usefuil the same electronics is when SecureBoot is disabled or in BIOS mode. Except for those PCs that actually can enable SecureBoot in BIOS mode, how thoughtful.
What's really needed from the author is fundamentally to get all distros onto the same shim first of all, so the Microsoft-signed spare keys for future Linux use built into the UEFI firmware do not all get blacklisted as fast in case events like that come along more often. In that case it's a lot more sensible to blacklist a single key for all distros rather than a bunch of keys at once because each major distro has a different one.
Then move on to address much further the deep security needs of the most sensitive users, whether they are using Microsoft-signed shims, or their own machine owner keys which negate the need for shims when they are in use.
Edit: corrected BOOTYMGR