A lot of that is already in ASN.1, for example for UTF-16 you've already got UTF-8 and given that even Microsoft have abandoned BMP strings I doubt any attempt to reintroduce it will get much traction, relative OIDs already exist, BCD strings are just constrained PrintableStrings and in any case UTF-8 won for all of the string types, Reference sounds like an EXTERNAL, OOB sounds like an ANY DEFINED BY, etc.
> for UTF-16 you've already got UTF-8 and given that even Microsoft have abandoned BMP strings I doubt any attempt to reintroduce it will get much traction
This is not reintroducing anything; the BMP type is already there, although its meaning is expanded (the existing BMP type is effectively a constrained subtype of UTF-16). Although most applications probably will not use UTF-16, it might sometimes be useful in some applications where it is more useful to store UTF-16 instead of converting to/from UTF-8.
> relative OIDs already exist
Yes, although I have given a standardized name and semantics to something that is allegedly already a common use (and is one that I often use in my own projects), which the official specification from ITU admits. It uses the existing OID and relative OID types (and the same type numbers as them), and is like a CHOICE between them (implementations may treat it as such).
> BCD strings are just constrained PrintableStrings
The abstract meaning matches that of constrained Visible (not Printable) strings, but the encoding is more compact.
> UTF-8 won for all of the string types
Although it is common (and some other formats don't support other string types), I disagree, and I think that one character set cannot be useful for all purposes, and furthermore that Unicode is not that good and has many problems.
> Reference sounds like an EXTERNAL, OOB sounds like an ANY DEFINED BY
