Key types and proprietary subtypes are now defined as compact size integers. Previously compact size integers were used only to encode the size of data. It was decided that it would be fine to use compact size integer for extensibility of key types, to allow for types larger than that can be encoded by just one byte. One of the advantages of using compact size integers for key types was that the code to decode them in the implementations that work with PSBT.
The problem is, the code that decodes compact size integers, at least in BitcoinCore, limits the upper range of compact size integer to MAX_SIZE = 0x2000000 (see ReadCompactSize() in serialize.h`). Other implementations might implement the same restrictions, to improve the chances to catch incorrect data.
I think it should be discussed how this issue can be solved.
It can be said that implementations should allow full range representable by compact integer (up to 2**64-1), and then some implementations will need to update their code, to have separate decoding function or add extra parameter to existing decoding function to be able to decode full-range compact size integers and retain the range check where it is needed.
Or we can say that the range from 0 to 0x2000000 is enough for any key type or subtype, but then this should be spelled out in the BIP. (Note that ranges beyond MAX_SIZE up to 2**32-1 can be represented by straight non-compact-size 32-bit values).
I'm not sure what is the right approach here, but I favour the second option.
