ASN.1 in 1984 was not too broad. It was too simple, and it was too targeted to tag-length-value encoding rules (which are stupid -- TLV is a crutch that is only maybe useful when you lack a compiler, which early on was the case).

ASN.1 today is as broad as it needed to evolve to be because its users needed it.

There is value in throwing away cruft, especially cruft that comes from the IT Middle Ages (before we decided to drop any non 8 bit word sizes, before UTF-8 became the almost universal string encoding, etc.).

Maybe, but ASN.1 is a Chesterton's fence.

Before you throw it away and reinvent it badly, acquaint yourself with it.

And you might notice that ASN.1 has a long history, but it's thoroughly modern today, and much more so than many alternatives to ASN.1 that have been created even in recent times.

I agree with this, and I think that overall the Chesterton's Fence principle should be applied more in software engineering.

What's hard is finding a set of "thoroughly modern" ASN.1 implementations that work together, and trusting that they will do so. The name is overloaded by the years of revisions and cruft.

Fabrice Bellard has a proprietary ASN.1 compiler that looks very modern and very very featureful.

Heimdal's ASN.1 compiler is getting to where we should separate it and make it a standalone project. It's really quite featureful, and it's also getting to where adding support for PER, OER, NDR, XDR, XER, JER, and other things should be quite easy: just write a bytecode interpreter for each of those. I only need NDR and JER, so I'll be adding those (already it can dump values as JSON, but it's not quite JER compliant).

Also, I've begun adding support for dumping ASN.1 modules (not just values) as JSON with an eye towards rewriting the codegen and bytecode generator in jq, and then maybe adding support for targeting languages other than C. It really helps to have a decent implementation to stand on for this, and I am really standing on the shoulders of giants here.