But the problem isn't with abusing strings, but abusing something that isn't data.

Abusing the string is the correct place to put poorly planned data because it's just data and it has a stable position in the data (and syntax) tree.

But consider this example:

    {
      "a": /* directive */ 42,
      "b": 42, // directive
      // directive
      "d": 42,
      /* directive */ "d": 42
    }

What does the code look like that has to reconcile the directive with the data it modifies?

That's a completely different and worse problem than someone "abusing a string" with something like `{ "a": "42 directive" }`.

I think JSON made the right call. People just confuse that with it being somehow forbidden to use comments in JSON config, but they're wrong. Just look at VSCode's config. It was possible all along despite decades of people whining in blogs.

We didn't need comments in JSON over the wire. We didn't need a new format. We didn't need another blog post about it. Just write your tool to accept comments in its config.

I don't understand what the problem is.

You can just make a parser that ignores comments, while still allowing them in the syntax. You don't need to store the comments in the AST, or to actually parse them. You just need to skip them.

That only works if you control the data that gets parsed.

Imagine you’re a HTML parser library author in 1998. You’ve been happily skipping comments. Now you get complaints that your parser doesn’t see JavaScript. Turns out that everyone has agreed that these new script tags should be embedded inside comments.

Should you keep skipping comments and tell your users you’ll never support this HTML that everybody else now considers valid?