GUID partition tables mean we don't need to coordinate identifiers. That's the point.

But in fact, we don't need to coordinate identifiers. Clashes in partition ID's are of no practical consequence.

A 32 bit "fourCC" would be more than adequate. It could even be constrained just to readable characters, like LNXF (Linux Filesystem) and LNXS (Linux Swap).

If another OS happens to use LNXF for something, and you have that OS in the same darn system, it doesn't matter. You just don't have that "foreign" LNXF in your /etc/fstab, and likewise it doesn't have the Linux ones in its equivalent of /etc/fstab.

The only thing that needs a clash-free label is the EFI boot partition, so the boot firmware can unambiguously identify all these partitions on all attached devices and offer them as boot options.

Why have them at all then?

If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.

Because we can usefully assign distinct values in a context like "Windows plus Linux box" in which we don't care about some exotic file system that was once used on a DEC VAX or whatever.

So why not use a single byte? How many machines do you know which have more then 255 filesystems on the one disk?

Why not a nibble and just use the other 4 bits for flags?

The point of this line of questioning is you're quibling over bytes which definitely don't matter in any modern context, at the expense of masses of extra management complexity to try and avoid day-to-day problems when people want to stand up new systems.

With GPT, if I want to make a new filesystem type for some application, I just generate a GUID and it will not collide without me needing to coordinate with anyone.

Indeed; one byte works for me. Four is a reasonable political compromise between "one byte works for me" and "oh my, what about clashes?"

16 bytes is an obvious example of the "second system effect" described by Fred Brooks in Mythical Man Month.

The fdisk utility now reduces the GUIDs to one byte codes that refer to the GUIDs. For instance, I remember that 29 is Linux RAID (previously FD). Will 29 always be Linux RAID everywhere? Probably not.

> With GPT, if I want to make a new filesystem type for some application ...

Four bytes could have an ample reserved range for local use by hobbyists.

Broad recognition of the code only matters if the application is very widely deployed.