I can think of three ways that this could’ve happened without either OS being broken necessarily.

One is that you’re still on an MBR drive (maybe you upgraded from Windows 7?) which can only have one single bootloader. The drive you pick to install Windows’ (or Linux’s) files doesn’t necessarily determine the location of the bootloader in that case. With MBR, both Windows and Linux are right to replace each other.

If you installed an UEFI system, this shouldn’t happen. There is, however, some broken hardware that causes this problem. Instead of registering a bootloader into the system on a normal path (say /boot/efi/linux/grub.efi), it’ll only boot the install medium/fallback bootloader EFI file. Both Windows and Linux put their bootloaders in the fallback location for these broken devices so they work. In this case both Windows and Linux are right to update these files and the problem lies with your broken motherboard. This usually happens with older computers.

There is another possibility. Microsoft got their Secure Boot key leaked over a year ago, and they’ve slowly been rolling out key updates so malware can’t use their key to hijack Bitlocker and bypass Bitlocker. If your bootloader hasn’t been updated to have the modern signing keys, and Microsoft renewed their keys, the motherboard may reject the bootloader. As far as I know there are new shims available, but with you speaking of reinstalling the bootloader to fix it, this may also have happened. A workaround would’ve been to disable secure boot, update the bootloader once the system has started, and turn secure boot on again, but Linux doesn’t warn you about this problem.

Microsoft is right to revoke their long-leaked keys, and this is the whole reason keys can be updated in the first place. Unfortunately, good tooling for secure boot doesn’t exist in Linux. In my opinion, the user should only deal with this issue once, during setup, and Linux should manage user keys for its kernel already instead of relying on the user executing a bunch of complicated commands. A combination of secure boot and an fTPM (hardware TPMs should be considered compromised at this point) have the ability to bring Windows-like security mechanisms to Linux, but so far no distro seems to bother.

It’s also possible that your motherboard just got its bootloader config corrupted. Mine does that sometimes, it’s a real pain. Grub does it, Windows does it, it’ll just garble up the bootloader entries and fall back to the fallback bootloader which is a 50/50 chance of booting either OS, basically.