> Protobuf and flatbuffers have different use cases in my experience, although that's somewhat limited.
This is true for the ASN.1 encoding rules as well.
> Protobuf at least also introduced breaking changes between versions 2 and 3. ASN.1 isn't perfect in this regard,
When has ASN.1 ever broken backwards compatibility? I've never heard of an ASN.1 backwards incompatibility. Maybe, if you stretch an interpretation of ASN.1 in 1984 to allow new fields to be added to `SEQUENCE { }` then the later addition of extensibility markers could count as a very weak backwards-incompatible change -- weak in that existing specs that use ASN.1 had to add those markers to `SEQUENCE { }`s that were actually intended to be extensible, but no running code was actually broken. I would be shocked if the ITU-T broke backwards compat for running code.
This is true for the ASN.1 encoding rules as well.
> Protobuf at least also introduced breaking changes between versions 2 and 3. ASN.1 isn't perfect in this regard,
When has ASN.1 ever broken backwards compatibility? I've never heard of an ASN.1 backwards incompatibility. Maybe, if you stretch an interpretation of ASN.1 in 1984 to allow new fields to be added to `SEQUENCE { }` then the later addition of extensibility markers could count as a very weak backwards-incompatible change -- weak in that existing specs that use ASN.1 had to add those markers to `SEQUENCE { }`s that were actually intended to be extensible, but no running code was actually broken. I would be shocked if the ITU-T broke backwards compat for running code.