/dev/sda is the new SSD. Linux Mint 21.3 is on /dev/sda5, and Windows 10 should be on /dev/sda1-4. To my understanding /dev/sda1 is an EFI partition.
When you ran the Boot Repair utility, the Mint Live disk you ran it from was recognized as /dev/sda, and your new SSD as /dev/sdb:
Disk sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk identifier: 88F93FC7-E70C-4253-845C-C3D93CC6658D Start End Sectors Size Type sdb1 2048 206847 204800 100M BIOS boot sdb2 206848 239615 32768 16M Microsoft reserved sdb3 239616 1257408925 1257169310 599.5G Microsoft basic data sdb4 1257410560 1258528767 1118208 546M Windows recovery environment sdb5 1258528768 3890251424 2631722657 1.2T Linux filesystem sdb6 3890251776 3907028991 16777216 8G Linux swap
It clearly used to be a GPT-partitioned, UEFI-bootable disk, but because the Boot-Repair was booted in legacy BIOS style and/or because you may have toggled the partition type of sda1 from ESP to BIOS boot, it assumed it was working in a legacy BIOS system, and has now "repaired" this disk into a BIOS-bootable GPT disk.
This is an unacceptable combination for Windows 10: it requires UEFI boot on GPT-partitioned disks, and BIOS boot on MBR-partitioned disks. No other combinations are supported by Windows, and here "not supported" means "does not work."
Your Boot-Repair-generated GRUB boot menu apparently now allows you to boot Mint 21.3 (although Boot-Repair may have mislabelled it as "Ubuntu" in the boot menu), Windows 7, and the old Mint 20.3.
When booting Linux Mint 21.3, sudo efibootmgr -v answers "EFI variables are not supported on this system. And I have no /sys/firmware/efi. But I do have the packages grub-efi-amd64, grub-efi-arm and grub-efi installed.
It looks like your Mint currently boots in legacy BIOS style; this is probably Boot-Repair's doing. The fact that you have grub-efi-amd64, grub-efi and efibootmgr installed suggests that Mint was originally installed to boot in UEFI style.
The presence of grub-efi-arm would be a mistake, unless you are also developing ARM software.
/dev/sdb is a prior SSD I had. It has Linux Mint 20.3, and an old Windows 7 (I don't care about the Windows 7, I'd like to keep for now the Linux to recover some data).
Under Boot-Repair, this was recognized as /dev/sdc:
Disk sdc: 223.57 GiB, 240057409536 bytes, 468862128 sectors Disk identifier: 0x000e99c8 Boot Start End Sectors Size Id Type sdc1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT sdc2 206848 266678271 266471424 127.1G 7 HPFS/NTFS/exFAT sdc3 266678272 468861865 202183594 96.4G 83 Linux
This is MBR-partitioned, and looks like it may always have been BIOS-bootable. It also seems to currently have a GRUB configuration that covers Mint 21.3, Windows 7, and the old Mint 20.3.
My BIOS does not have any Legacy option, or UEFI option.
Clearly it supports UEFI, with a fixed preference on Legacy-style boot if any legacy-style boot targets are available. The fact that it provides no options to adjust that is unfortunate.
When choosing to boot from external media that is bootable in both styles (like Mint Live and most OS installation media), you should look carefully: is there just one menu item for the external media you're looking for, or is there two of them? If there is two, then one would be for the legacy BIOS-style boot, and the other for UEFI. When installing operating systems, the boot method used to boot the OS installer will also determine the boot method of the installed OS.
To make your Windows 10 work, you would have to first either convert your SSD from GPT partitioning to MBR style, or change the sda1 partition from "BIOS boot" back to EFI System Partition (ESP). In either case, you will then need to use the Windows 10 installation media's "Repair boot" functionality to rebuild the Windows bootloader of appropriate type (BIOS or UEFI). Be careful to boot the installation media in the appropriate mode.
After that, you would have to recover the boot of your Linux Mint installation(s). For that, I would recommed avoiding Boot-Repair: instead, you should just chroot into your primary Mint installation, ensure you have the GRUB packages for the desired boot process type installed: grub-pc and grub-pc-bin for legacy BIOS boot, grub-efi-amd64 and grub-efi-amd64-bin for UEFI without Secure Boot. If you also want Secure Boot support, you should add grub-efi-amd64-signed and shim-signed to the list.
With legacy BIOS boot, if your expected boot disk is not /dev/sda when chrooting, you should create a /boot/grub/device.map file to indicate which disk will be the first disk detected by BIOS when booting normally, e.g.
(hd0) /dev/sdb
if the situation is similar to when using Boot-Repair, i.e. the removable media appears as a temporary /dev/sda.
After creating the device.map file, you should run
grub-install --target=i386-pc /dev/sdb
to write a BIOS-style GRUB to the Master Boot Record of the disk that is currently sdb (but will be sda once booted without the removable media).
If you choose to boot in UEFI mode, you won't need the device.map file. The command to install UEFI version of GRUB is just:
grub-install --target=x86_64-efi /dev/sdb
where /dev/sdb is the disk that contains the EFI System Partition. If you want to support Secure Boot, add the --uefi-secure-boot option.
If you can't avoid booting in legacy mode from removable media to recover your Linux boot, but still want to set up for UEFI boot (which can be tricky given your BIOS offers no options to control the boot mode), you can install GRUB in UEFI removable media mode first:
grub-install --target=x86_64-efi --removable /dev/sdb
(Likewise, add the --uefi-secure-boot option if you want Secure Boot support.)
After this, you may have to explicitly select to boot from the SSD in order to have your Mint boot on its own in UEFI mode. Once there, you can run sudo grub-install --target=x86_64-efi --uefi-secure-boot /dev/sda to install in a way that should produce a clearly named, identifiable BIOS boot order option for Mint.
If using [g]parted, keep in mind that for some reason, it represents the various GPT partition types as "flags". When selecting the ESP flag, it will set the type of the "flagged" partition to ESP, for example. For backward compatibility, the "boot" and "ESP" flags are considered equivalent by [g]parted on GPT-partitioned disks.
