Reason number 1: aliases and anchors. Reason number 2: allowing comments.

JSON is a terrible config format, and an ok data interchange format.

Agreed. It amazes me that we got out of the XML-for-everything era with a lot of people thinking the problem was XML, and not the for-everything part. JSON-for-everything is just as maddening to me.

Comments was the reason for me to move from JSON to YAML in config files. I remember perfectly fine what every option does, but adding comments to each option is a must when it comes to sharing my code with anyone else.

If its a config file I'm not sure why you'll need comments. Comments / documentation should be in the system you'll do the config for. If your set options are that quirky / need documentation; why not explain them in a README?

But maybe I misunderstood. Can you give an example of a comment that makes sense / is required in a configuration JSON?

> If your set options are that quirky / need documentation; why not explain them in a README?

Mostly because I don't know whether the person customizing my code will read the README, but they'll definitely see the comments I wrote right before the configuration option itself.

With comments and some extra whitespace, they can go through the file line by line, read what a specific option does, configure it properly, and move on to the next one. No back and forth to the README required.

JSON's finicky about commas. Quotation marks everywhere are a visual noise. Comments are accepted by many parsers, but not by all of them.

Something like http://www.relaxedjson.org/ is a JSON we need. An implicit root object would make it almost perfect for writing configuration.