It's a case of someone designs a tool to do A, then a lot of people who have problem B see it and go, that's almost what I want, with just a few adaptations. J

It's a case of someone designs a tool to do A, then a lot of people who have problem B see it and go, that's almost what I want, with just a few adaptations. JSON in its original form is fine if you want to pass data from a server to a browser's fetch request. No need for comments. (If you're passing data from one process to another, and neither of the processes is a browser, have you considered protobuf?) For humans writing config files, such as the VS Code one where you sometimes need to go in and do things by hand, both the ability to temporarily comment stuff out and do put comments above particular settings, are extremely useful if not essential. The "comment: '...'" approach doesn't work here or anywhere else where you have a schema to validate against. Comments are not part of how JSON was originally defined. It's technically correct (the best kind of correct, some say) that comments are not part of the spec. But comments are sure how most people who edit JSON as a human [want to] use it. If the spec says A but everyone is doing B because that's what best solves their problem, then either you write a new spec and call it JSON++ or JSON-C or something and watch most people switch to that, or you adapt the spec in the first place. We've seen this with markdown (ok, commonmark) and HTML already, among other things.