Windows does not have a separate NTFS boot partition. MSR is not it (check the size and content). Windows Boot Manager and BCD are stored on the EFI partition. Windows Boot Manager itself does understand NTFS: it loads winload.efi, ntoskrnl.exe and core drivers from the system root itself. This way, Windows is not going to have the common linux problem ("update failed, /boot too small").
Two partitions are needed only for Bitlocker; one has to be unencrypted.
Similarly with Apple: they use APFS subvolume for boot files. They do not bother with multiple partitions and static allocations, guessing, what size is going to be OK. They can use as much or as little space as they need.
--
With Linux, I've been using btrfs subvolume for /boot. It works with "normal" distributions, grub complains (it cannot write there; I find that OK). The dynamic nature of the space used is great. It doesn't work with ostree-based distributions (Fedora Silverblue & its ilk); ostree cannot generate proper BLS and grub.cfg for subvolumes.
I'm talking about the WinRE partition, which is required to boot Bitlocker encrypted boot partition (and Bitlocker is enabled by default). Enabling Bitlocker without one results in an error message, and Windows happily recreates/resizes the WinRE partition on every (OS) upgrade by simply reducing the size of the main partition. It has been a long time that the size of the ESP is not enough for all the stuff that Windows wants to do on preboot.
For the record, and showing again the unfairness of the entire MS monopoly situation, most commercial UEFI implementations out there happen to understand NTFS. This allows e.g. a Windows pendrive to boot no matter how the user formats it.
Two partitions are needed only for Bitlocker; one has to be unencrypted.
Similarly with Apple: they use APFS subvolume for boot files. They do not bother with multiple partitions and static allocations, guessing, what size is going to be OK. They can use as much or as little space as they need.
--
With Linux, I've been using btrfs subvolume for /boot. It works with "normal" distributions, grub complains (it cannot write there; I find that OK). The dynamic nature of the space used is great. It doesn't work with ostree-based distributions (Fedora Silverblue & its ilk); ostree cannot generate proper BLS and grub.cfg for subvolumes.