Naturally that's also the regular way you can also boot into either partition bare metal when you want.

Unmounted or hidden, an additional separate specialized FAT32 boot partition has been common for Windows since long before UEFI & GPT partitioning became mainstream.

Usually the first active primary partition on a Windows 7 BIOS PC, a few hundred megabytes of FAT32 were there specifically to hold the BOOTMGR file and its associated BOOT folder, (where you could build a Windows bootmenu) which would point from there to any of your main NTFS partitions that had a version of Windows installed.

That regular Windows bootmenu (in BIOS) could also be used to point to the GRUB-based bootsector from a type 83 EXTx Linux partition on the same HDD. This would boot the Linux like normal. Even though Windows would not mount nor access the Linux partition. But Linux could mount and access the Windows partition.

Alternatively, on a fresh BIOS partitioning layout, the FAT32 Boot partition can be upsized to a few GB (instead of mere MB) and then a copy of an entire live Linux fileset from the bootable Linux DVD can be placed there right next to the Windows BOOT folder. The contained live Linux squash filesystem is then booted into memory from the FAT32 volume using the Windows bootmenu, with GRUB, or even Syslinux which can boot the Isolinux-launchable DVD fileset when the fileset is stored on a FAT32 volume.

An advantage of this arrangement is so (live) Linux is avaiable bare metal when needed on an otherwise unchanged Windows PC, without having any EXTx partitions. As more distros gained access to NTFS it became possible to place the Linux live folderset right there on the NTFS volume alongside Windows, so there was another option.

In BIOS mode Windows 10 (and even Windows 11 in BIOS for extra credit) works just like Windows 7 for this.

For UEFI a FAT32 ESP is almost always in use but Windows bootloader will not boot Linux in UEFI. But the /EFI/BOOT folder in the UEFI ESP is not dedicated to Windows like the BOOT folder was under BIOS. /EFI/BOOT contains the key BOOTX64.EFI file which is basically a renamed OS-specific bootfile placed there by the most recent OS that was installed or had its bootfiles updated in common ways.

BOOTX64.EFI then points hardcodedly to one of the associated /EFI/Microsoft or /EFI/ubuntu, etc folders there on the boot partition which will contain a Windows or Linux bootmenu accordingly.

The /EFI/Microsoft folder contains the regular Windows bootmenu which accesses any of the Windows OS's that are installed on any of the NTFS[0] partitions that are unhidden at the time.

The /EFI/ubuntu folder contains the GRUB bootmenu which accesses any of the Linux OS's that are installed on any of the EXTx[0] partitions. Additionally the GRUB bootmenu can be configured to have a Windows bootentry which then chains to the regular Windows bootmenu in /EFI/Microsoft/Boot/BCD. Also in GRUB a bootentry can be added to launch a live Linux fileset stored on a sizable enough ESP FAT32 boot volume similarly to how it's done in BIOS.

Interestingly, on a Windows XP PC to begin with you could install to a different folder than the default WINDOWS (such as WINNT or WINXP). Afterward if you protectively renamed Documents and Settings & Program Files from the command line of the NT6 install DVD, you could then install NT6 into its own default WINDOWS folder alongside XP on the same partition without conflicts. The real Documents and Settings can then be unveiled and an NTLDR entry added to the NT6 bootmenu. BOOT.INI can then handle the NT5 & DOS booting as before and NT5 when booted can share the Program Files folder with NT6 as long as you are careful, since NT5 does not need to run anything in the Program Files folder when you boot. Often you can install an NT5 program into the same Program Files folder shared with NT6 this way and there is no conflict whatsoever.

[0] a wider variety of filesystems are becoming supported as years go by.