Does booting work in pairs like legacy/MBR, EFI/GPT, BIOS/MBR, EUFI/GPT?

BIOS vs. UEFI

Both BIOS and UEFI are standards that PC motherboard's firmware must follow. It's the first piece of code that starts with the PC executes when starting up. Its role is to initialize hardware and pass control to another program, called bootloader, which in turn will boot into OS. This process is called booting.

BIOSes were used for a long time, but they were designed with very, very old hardware in mind. Over the years the original concept of BIOS was updated and extended as technology evolved, but the need of maintaining backwards compatibility was a big PITA, so eventually BIOS was dropped in favor of UEFI. Almost all consumer computers and motherboards manufactured in the last 10 years run UEFI rather than BIOS.

The term "BIOS" is still often incorrectly used to refer to UEFI in modern PCs because it's hard to change people's habits.

EFI vs. UEFI

EFI is also a PC motherboard firmware standard, but it was developed by Intel with server hardware in mind. UEFI is an evolution of EFI aimed at general PC usage, including consumer-grade computers. UEFI uses very similar concepts to EFI, so sometimes UEFI nomenclature uses "EFI" in names of things, most notably EFI System Partition. You can think of UEFI as EFI 2.0.

BIOS vs. Legacy vs. CSM vs. EFI/UEFI

(U)EFI uses a completely different boot mechanism than BIOS. Old booting techniques that were used with BIOS don't work with plain UEFI anymore, but there's the Compatibility Support Module (CSM) - an optional component of UEFI which provides backwards compatibility with BIOS booting. This old boot mode is called legacy boot, BIOS boot or CSM boot in UEFI setup programs (the thing you access by pressing some key on boot to access UEFI settings).

In my experience most UEFIs let you enable BIOS boot in addition to UEFI boot, but in some you have to choose either one or another. There are also platforms that don't support CSM, for example Intel's Gemini Lake.

MBR vs. GPT

Those are partition table styles. A partition table is a data structure on a storage device (typically a HDD or SSD) that describes virtual partitioning of that device. By virtual I mean that it doesn't really change anything physically about the device, it's just a description of user's intent. It's operating system's job to read the partition table and respect it, exposing the disk as a collection of independent partitions rather than one large storage device.

There are many old partition table styles invented by various companies for their purposes, but the one that stood the test of time is usually called MBR nowadays. It shows its age, but was good enough for a very long time. It has two major limitations: first, it supports up to four partitions. This was worked around by inventing extended partition: a partition that takes a single partition slot, but holds unlimited number of inner partitions. The other limitation is impossible to work around: it's unable to address sectors over 2^32-1. It sounds like a lot, but we've already hit it: it's 2 TB for 512-byte sector disks or 16 TB for 4k sector disks. If your disk is larger than this, MBR will only let you partition up to that much space.

GPT is MBR's successor. It supports up to 128 partitions and addresses so large we won't reach them for decades, maybe never.

BIOS+MBR and UEFI+GPT

These are the natural pairings, but you can use BIOS+GPT or UEFI+MBR if you wish.

MBR is called so after the Master Boot Record - a small chunk of partition table which holds a primary bootloader. When BIOS boots, it executes this piece of code. This MBR record is not part of any partition, it's stored directly in the partition table. This approach is easy to implement in firmware such as BIOS, but it's very limited: the Master Boot Record is tiny, so all advanced bootloaders try to fit a minimal filesystem driver in there and load the rest of their components from the system partition. It's also hard to work with without dedicated tools.

GPT is actually defined by UEFI spec and takes a different approach. Since UEFI isn't meant to be as thin and simple as BIOS (it's basically a small operating system, including the ability to load custom modules), its designers didn't bother with BIOS's "KISS" approach. Instead UEFI includes drivers for FAT-family filesystems and can be configured to load bootloader directly from a partition. Basically the filesystem driver which everyone tried to store in MBR is now provided by the platform, along with a built-in boot manager.

So, for BIOS (or CSM) to boot, you need to have MBR record in your partition table. GPT specification actually covers this case. The same area which would be used in MBR partition table for the MBR record (confusing, huh?) is reserved in GPT. It's so-called protective MBR, just in case someone would want to boot GPT disks from BIOS.

For UEFI you typically need an EFI System Partition (sometimes referred to as ESP). It's formatted with FAT-family FS (generally FAT32) and used to store all bootloaders for all operating systems in subdirectories or a directory called EFI (EFI legacy, see?). These bootloaders are then added to boot options list in UEFI setup or by OS installers to make them selectable in UEFI's built-in boot manager.

Alternatively, if media intend to provide just a single UEFI boot option (like for example OS installation media), they can provide a bootloader file called EFI\BOOTX64.EFI on a FAT family-formatted partition. These are automatically imported into UEFI boot manager without any need to configure them.

So BIOS+GPT is possible thanks to protective MBR and UEFI+MBR is possible because you still can create an EFI System Partition. These combinations are not supported on Windows, though.

I have Windows installed on one disk, how do I install Linux on another?

Disk technology, ie. SSD vs. HDD, isn't relevant. I'll use these two only as names of your disks.

I'd suggest to:

Consider repartitioning HDD to GPT - just to modernize it and avoid the annoying partition limit. If you have other data on that disk that you want to preserve, a lossless conversion most likely won't be possible, so consider skipping this step.
Create an EFI System Partition on HDD. You could use the one you already have on SSD, but this would create a single point of failure - the OS on HDD won't be able to boot without SSD. One ESP per disk is safe and supported everywhere (theoretically you can have as many as you want, but you can expect some problems with Windows upgrades).
Create a partition on HDD to store Linux and your files.
Install Linux in UEFI mode.

Tips:

If you don't intend to use CSM, it's best to disable it in UEFI setup to avoid confusion.
Remember to pick the correct ESP in the installer. For Debian, choose Use as: EFI System Partition. For Ubuntu I think it will be sufficient to select the right disk in bottom dropdown.
Don't waste your time trying to install Kali Linux. It's not designed as an universal OS and not intended to be installed. If you want to learn Linux, pick something universal and aimed at average users. Debian is what Kali is based on. Ubuntu is a user-friendly, modern Debian derivative with huge userbase (and thus great support). I personally like Pop!_OS which is an Ubuntu derivative with some tweaks and quality-of-life improvements. If you just want to use Kali, boot it from USB like it's intended to be used.

You are only confusing yourself: You are in EFI+GPT mode and this is OK.

Disk 1 is where the EFI boot code exists, and it will direct the boot to the right installation on whatever disk according to your choice on the boot menu.

Some advice: Avoid modifying files of the one installation from the other, disable fast boot in Windows and take a backup image of Disk 1 before starting installing Linux (AOMEI Backupper Freeware is the one I use). I remark that Linux is also available under Windows in the Windows Subsystem for Linux (WSL) without dual boot.

You can search for more information on the internet - much is available.