That's the big issue with these formats. There's an inevitable minimal complexity in any data format, and it has to be dealt with somewhere. The "simple" specifications optimize for ease of reading the spec, which is a kind of marketing trick to make it enticing, but in reality leaves so much ambiguity that you get the kinds of problems in the article. A tighter spec on the other hand reduces ambiguity but appears more complicated to anyone reading the spec.

I went the tighter spec route in https://concise-encoding.org because that's the only safe way to go, and also versioned the spec AND documents because I know that even with the care I'm taking there will be mistakes to fix in the spec after release.

Specs should be hard to read. They must be finely detailed and leave no ambiguity. Human "browseability" is what docs are for.

Aside: I like this data format. What prompted you to make your own?

I couldn't find an existing format that had the types I needed, and also an unambiguous text/binary twin format. Then once I got started, my pent-up wish list and gripes over the formats I've used in the past came to the surface ;-)