In my experience this behavior is present whenever you try to run grub with 2 identical OSs. I've tried it a couple of times so I could have one OS and use another identical OS for experimentation. Both times grub would get "confused" and always boot just one of those OSs. Both times it was with 2 ubuntu based distros. I have "guessed" that it might work if both OSs had different kernels but I haven't had the time/desire to try it.

If you install grub before you setup /etc/fstab that can have results like that. Re-installing grub to the MBR overcomes that if the /etc/fstab is accurate. And you have a version of grub that defaults to UUIDs. The UUID is partition specific. And at times the grub.cfg that generates can get the UUIDs wrong. A little manual intervention can set things straight. You can even edit those parameters in grub at boot time ("e" for edit). You can change the UUID with various tools like e2tunefs and xfs_admin, just be sure to update /etc/fstab and the bootloader. I doubt that fuse can handle the UUID part of NTFS without adverse affects on windows, but maybe. Not that windows and it's million copies of everything in the registry will like having that changed, even when changed by official tools under blessed OSes.

What do you mean by an "accurate /etc/fstab"? Are you mounting all the partitions at boot?

Certain install methods (chroot) copy the /etc/fstab from the host, or leave it completely blank, which is not accurate relative to the "new" install. Grub will take the copy literally without validation if installed while in this configuration. And update-grub in debian will take the UUID that was in play, when grub was installed. Basically first boot woes for installs that have yet to be booted on bare metal. Fairly niche I would assume as an install with an incorrect /etc/fstab wont boot (or at least wouldn't before systemd). A blank /etc/fstab boots fine these days under systemd, but / is typically mounted read-only when that is the case. With it's own set of special issues.

There are two ways around your problem. You could use filesystem labels in grub instead of UUIDs and/or you could change the NTFS UUID with a hex editor.

Since one of the partitions already has a label you could use that instead of the UUID.

blkid:
/dev/sdc1: LABEL="WxP" UUID="5E70A7E470A7C0DF" TYPE="ntfs" PARTUUID="4b879f19-01"
/dev/sdb1: UUID="5E70A7E470A7C0DF" TYPE="ntfs" PARTUUID="000b3f5d-01"


search --set=root --label WxP

For the other partition sdb1 as I said:

ntfslabel /dev/sdb1 new-label

Then in grub:

search --set=root --label new-label


Actually Windows has no concept of filesystem UUIDs. The 32 digit UUIDs used for Linux filesystems as well as lvm volume groups and physical volumes are a Linux concept. The 16 digit UUIDs that show up with blkid for NTFS partitions are generated from the volume serial number in the NTFS superblock. Microsoft actually provided detailed descriptions of the superblock in NTFS filesystems. Since UUIDs are a Linux concept there are no Windows tools to change them.

If you change this volume serial number with dd and a hex editor a different UUID will be generated. I found a web page which describes this procedure.

https://www.linux.com/blog/howto-mod...ntfs-partition

Basically you copy the NTFS superblock to a file using dd, use a hex editor to change a few bytes in the volume serial number, and write it back with dd.