You are saying as if there was an apology or it should be needed for some reason.

For any spec there are people who want something spec doesn't do and people writing the spec need to say no to requests that they consider not in scope as much or more often than they say yes

There was literally an apology, a douchebag backhanded false one, but still acknowledged explicitly that there was a thing he knew everyone would want, and knew it would "make some people sad".

Comments are not some weird thing one person wants for their weird reason that no one else needs to care about. It's like leaving out a letter from the alphabet.

One wants comments, another wants single quotes, third wants ...

Just acknowledging someone wants something out of scope is not an apology

It's not out of scope, because this is not a binary data format.

Saying "I intended to make a defctive thing doesn't" doesn't change the fact that it's defective.

A car without windshield wipers is defective, or at best inexcusably limited. Saying "I only designed it to use in the sun" doesn't make it suddenly perfectly useful.

If you want to try to say that json was actually intended to only be used in special conditions like an exotic car with no roof, then it's fair for everyone else to say "Ok, well that intentional design is a crap design of limited use. People actually need a car WITH windshield wipers."

The simple fact that it's a text format invalidates all the attemped arguments that it's just a machine to machine data format never intended for humans to mess with. People aren't "holding it wrong".

It doesn't mean if it's text it must have comments. Simpler format means more people use it. Also parser reliability and speed.

CSV has no comments and is probably more popular than json.

And everyone complains that csv sucks and misses necessary features.

But everyone uses it. If the parser was more difficult it would not be literally everywhere and a go-to.

Then why did he invent json and everyone else invent yaml and toml and xml etc if csv already existed and was so complete?

If small parser was the most important, that's what binary formats are.

Or if the data needs to pass through a text handler that can't handle binary, we already had csv and a few different standard and cheap encodings.

csv's excuse for lacking some of the bare minimum features is that csv was first. Csv is from the time of typewriters and handwritten data. What would eventually become known, the most common needs, just hadn't been encountered yet.

A single person did not create csv after 40 years of seeing what is needed, and decide that csv shall not have an expected functionality in it's spec. There essentially isn't even any spec for csv. No one explicitly authored it. It's a typewriter format.

csv continues to get used after that point because of inertia. Once it's used many places, it continues to get used in new places because most new things have to interoperate with the existing ecosystem if you want to sell to the most possible customers.

Also csv, unlike json & similar, IS a pure data format, not used for things like configuration, because it's really only barely human usable, because the columns don't line up and there's no form of annotation other than a header record. Not to mention every part of the format, quotes, commas, even newlines, are valid data that may appear in a field, and so the only way to read the file is to manually reproduce the streaming state-machine in your head.

If something as limited as csv is so good and doesn't need anything else, then why did he invent json when csv already existed for jobs that narrow in scope?

csv is not remotely proof that text formats don't need annotation.

People keep bringing it up that "anything can be abused" but the point is that if you want to abuse something, abuse the simple parseable data rather than comments in the syntax tree.

Your two examples are just two examples of why we don't need comments for data interchange: yes, you put the data in a trivial, stable position in the parsed data that all parsers can parse rather than write some sort of DSL that has to be extracted from comment nodes that may appear in various places in the tree.

Turning this:

    { "key": "value" /* directive */ }

Into this:

    { "key": { "value": "value", "info": "directive" } }

Is the whole point. The more "abusive" you imagine the contents of "directive" to be, the more reason it should exist as the latter data, not more reason we should accept the former.

The whole point is you can't just add your own new keys/values/fields.

Most json users are not writing all of the software that both generates and consumes the json.