> What kind of values are [<whitespace>a] and [a<whitespace>] supposed to be?

I don't understand the qustion. They are supposed to be exactly that, [<whitespace>a] and [a<whitespace>]. I assure you, I've encountered many situations, where whitespace at the beginning or the end of the value is actually meaningful for reasons you (creator of the app) have no control over.

> Why should JSON never be used for configuration

Many reasons, actually, but the most important (IMO) being that original JSON specification doesn't support comments, nor most actual parser implementations do. Configuration file that doesn't support comments is trash and causes very real inconvenience for users. Using additional key values for comments (even if such atrocity doesn't bother you conceptually) isn't a solution in many cases (for example, when your intention is to comment out a list item).

> original JSON specification doesn't support comments

Just for the record, JSON initially had comments and they were later removed according to Douglas Crockford.

It is only now, that I realize, that [<whitespace>a] and [a<whitespace>] are really supposed to be 1 string inside a list. However, I already see problems with this kind of syntax:

[<whitespace>a,<whitespace>b]

How will this be interpreted/parsed? Will there be a whitespace before "b" after parsing? That would mean, that I am not able to separate visually more clearly, by adding a whitespace between list elements, which is widely considered to be a good practice in programming languages. The reason is readability.

The next thing is, that on the same line whitespace is added, but what about multiple lines defining a list? Here we do not add the line breaks and indentation to the string. It's not consistent in this way.

So I personally would never write string like that. I would always make use of quotes in such situations and probably in YAML in general, simply to make it clear, that I do wish to have the leading whitespace in the string, and it is not simply a typo, resulting from removing a former first element from the list.

JSON is limitting, but for configuration I think it's kind of limitations are often good. With comments in JSON I am still not sure, because sometimes I'd like to write them there, but would not like to include another dependency, only to be able to parse away the comments from JSON. Then I better write good docs elsewhere.

Or you can do it this style, but yeah, good point. I can see now why a lot of apple config files are still XML. https://www.freecodecamp.org/news/json-comment-example-how-t...

JSON lacks comments and will fail for a missing or extra comma, so it's not great for configuration written by humans.

You can use HJSON which is the json with comments. It's fully compatible with json so easy to introduce into anything that does json. https://hjson.github.io/

Failing with an extra comma also makes it harder than necessary to write JSON by machines.

JSON5 also supports comments and multiline strings with `\`-escaped newlines: https://json5.org/

Triple-quoted multiline strings like HJSON would be great, too.

I'd rather take "extra comma" failure than "extra space" space failure. First one can be caught by any IDE, second one will take you a couple of minutes to find out (when building CI for example).

[<whitespace>a] could be a markdown string that begins with code.