This fmtid+pid combination is historically related to OLE (yes, that's pretty old).

At that time, the fmtid (format id) was like a category, and the pid (property id) was the property identifier in the category. For example, you have here the first FMTID defined: Predefined Property Set Format Identifiers. These properties are still used for Office documents (Author, Keywords, etc.) So you had many properties per category (so few fmtid for a lot of properties), but the combination of both fmtid and pid always make the property unique across space and galaxies.

Others FMTID appeared since, you can have a look at in in Windows SDK's propkey.h: FMTID_AudioSummaryInformation, FMTID_Volume, FMTID_ShellDetails, etc...

Today, for some new properties, the FMTID does not mean anything anymore. For example, the System.Contact.Birthday has a fmtid of 176DC63C-2688-4E89-8143-A347800F25E9 and an id of 47, but the fmtid has no special meaning, and is not defined specifically, so it in fact could be used solely for the key.

So, for a given property, you must consider the key is still the combination of both (hence the structure name: PROPERTYKEY), but you could define your own properties with pid as something greater or equal to 2 (as the official doc specifies) and fmtid as a new guid if you prefer. I personally still prefer to define one common FMTID for a group of properties.