There is a big but though: whether the loss of interoperability for those cases was any real loss. Those people wanted their own files parsed a specific way by their own infrastructure. Their files already weren't meant for every regular JSON parser: if they wanted wider interoperability they'd had dropped those comments.

And nobody stops them from continuing to use those meta-parsing semantics even if JSON-standards prohibits comments.

I think Crockford was wrong in his objection. It shouldn't have been his concern.

> "Oh no! Bad actors might abuse this […]

There's no "might" about. This is exactly what happened in the early/beta days of JSON, per Douglas Crockford, creator of JSON:

> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.

* https://web.archive.org/web/20190112173904/https://plus.goog...

* https://archive.today/2015.07.04-102718/https://plus.google....

> […] absolutely necessary feature […]

It's so "absolutely necessary" that JSON has found hardly any success and is struggling to find a use case or a niche… /s

Or it seems that JSON works just fine without comments, especially as a data exchange format, which contradicts that claim that it is "necessary" (absolutely or otherwise).

I've missed comments in JSON myself, when writing stuff like configuration files. But interchange formats are a different beast, not really meant to be read by humans. And if they need comments to be comprehensible, one might wonder whether the scheme chosen was insufficiently self documenting in the first place.

Which, if dropped, are a clear change to the document in question. Whereas a dropped comment would have to be considered equal, even if the "special comment aware software" might not agree at all. I'm not happy with the decision, but I can't refuse the argument some merit.