I don't think any of these suggestions make JSON easier to read, generate, or consume. What problem are you setting out to solve?
Opening paragraph: "JSON is strict. Keys need to be quoted; strings can only be double-quoted; objects and arrays can't have trailing commas; and comments aren't allowed."
If this represents a comprehensive list of the problems JSON5 solves I think you'll have a hard time rallying people around your cause.
Yes, I realize I didn't explain it as well in the README as I had in conversations and emails.
I find JSON tedious and error-prone to generate by hand. I also frequently wish I could document the data with comments.
Others have written about these same ideas, e.g. [1]; after feeling the frustration for over a year, I decided it might be productive to actually build a JS parser to get the conversation started.
My main use cases are Node/npm package.json files, and test case data.
> I find JSON tedious and error-prone to generate by hand. I also frequently wish I could document the data with comments.
I whole-heartedly agree with you on the tediousness, but JSON has this dubious double-nature that it is sometimes written by hand but mostly used as a protocol. As a protocol we want (and I would even argue need) this strictness since it makes day-to-day operations easier and parsers generally more reliable (how many times have we seen someone implement their own JSON parser? Now, what about XML? The first is a nice evening the latter is, well, not...).
As for package.json, I would argue the problem is their choice of serialisation rather than with JSON itself. Right tool for the wrong job. YAML would probably be a better pick.
Opening paragraph: "JSON is strict. Keys need to be quoted; strings can only be double-quoted; objects and arrays can't have trailing commas; and comments aren't allowed."
If this represents a comprehensive list of the problems JSON5 solves I think you'll have a hard time rallying people around your cause.