In any case that is far beyond the original scope of booting old PC OSes, which MBR support alone serves really well (99.9% of the way there, really), which is why I assumed by default you were thinking of MBR, not some other weird scheme.
MBR is two things with the same name. It is both the format of the storage device and describes a booting mode using a master boot record and up to 4 partitions.
GPT is one thing. It is a format for a storage device. It is the alternative to the MBR format for storage devices. It has nothing to do with (U)EFI.
BIOS or BIOS/csm are not types of formats for storage devices. They are types of boot processes. (U)EFI is another type of boot process.
You can easily mix and match boot types (BIOS/csm vs UEFI) and storage device format types (GPT vs MBR). As others have said, there may be some slight incompatibilities on some rare hardware/software configs, but mostly it just works.
I invite you to read what I said again.
I am not sure what I said that was incorrect though. As I'm always looking to learn, which bit? I am currently assuming the 'rest' about GPT on true BIOS machines. I suppose I have never booted off GPT formatted disks in true BIOS machines. I always boot off MBR formatted disks and just used the GPT as storage/etc.
But I'm unclear on how this would break things since you can still have the MBR in the first sector on a GPT formatted disk. And how could the true BIOS motherboards detect GPT format on the disks when they don't know about it?
Ideally, BIOS/CSM systems should not care about what type of partition table format a disk uses, and just boot by loading the boot sector (the 1st sector), and passing control to it.
In the real world, some machines will check for whether an MBR exists (by MBR meaning the partition table contained in the first sector, also called "msdos" partition table, naming varies depending on who you ask), some of them will check whether there is any partition set as active in said MBR, some of them will, indeed, check if there is a GPT (past any protective MBR), and ignore such disks - possibly because firmware writers thought that no GPT disk should be bootable on BIOS systems (Windows doesn't support it, so...), to avoid passing control to an empty protective MBR and possibly crash or hang as a result.
While the space wasted by GPT and partitions and by the arbitrary alignment rules used by various formatting tools is not great, I do not see any reason why it should exist. The space wasted now with GPT and UEFI is several orders of magnitude greater than it was with traditional partition tables, so eliminating it has become more attractive.
Such SSDs and HDDs are not bootable, but for me this is a desirable feature, not a bug. I boot my computers either from Ethernet (e.g. most of my servers) or from a removable USB memory.
The SSDs and HDDs with a whole-disk file system are also wholly encrypted. As in a proper encryption implementation, there is complete separation between the encrypted data and the encryption key. The encrypted disks or their hosting computers do not contain any information about decryption, unlike in many systems of disk encryption. The encrypted decryption keys can be found only on external or remote boot media, which are not normally associated with the hosting computers.
I wouldn't recommend that. It makes the disk appear to be empty to many tools (and possibly some operating systems), which could lead to data loss. That's the reason GPT has the protective MBR: it makes the disk appear to be full to legacy tools which don't understand the GPT format.
Windows frequently overwrites any bootable Linux drive, so it might have even less restraints with an apparently empty drive that does not have GPT structure.
Because of the risk of Windows messing with them, I also do not insert any of my bootable USB memories in a live Windows computer, even when they have GPT structure. For data interchange with Windows, I use only clean and non-bootable exFAT formatted USB memories.
I am not the OP and I do not do this. However...
Yes, the disk space used is a rounding error and one far right of the decimal point.
But there is extra space used in the human brain that sets this up.
Instead of `/dev/sda1` it's `/dev/sda`. Instead of `/dev/nvme0l0p1` or whatever (I own almost no NVMe kit) it's `/dev/nvme0l0`. And so on.
This could be helpful; I can certainly imagine it simplifying things somewhat.
For instance, whole-disk btrfs. Or old BSD partition schemes.