Use “, “ as delimiter for json-objects.

[TurpentineDistillery]

This is rather subjective, but the rationale for this is that serialized json-object is ,-delimited sequence of :-delimited pairs, so having an extra whitespace between the elements would make it easier to visually parse.
e.g.

{"foo":1,"bar":[123,456],"baz":"qux,quux","quuz":true,"corge":"grault"}
vs
{"foo":1, "bar":[123,456], "baz":"qux,quux", "quuz":true, "corge":"grault"}

This would be a one-line change.

[gregmarr]

Are you referring to dump()? Changing this would result in it no longer being "the most compact representation".

 @param[in] indent If indent is nonnegative, then array elements and object
    members will be pretty-printed with that indent level. An indent level of
    `0` will only insert newlines. `-1` (the default) selects the most compact
    representation.

[TurpentineDistillery]

That's right, that wouldn't be most compact, although json format is not most compact to begin with, to say the least, and what's a few more bytes between friends? ; )
This is rather minor, so it comes down to whatever @nlohmann prefers.

[nlohmann]

I don't think it's a good idea to change the default , to , . The former has a rationale; it is the shortest representation. The latter seems arbitrary.

In #229 we had a discussion about how to pass more preferences to the dump function. We did not find a nice solution there. It is a shame C++ has no named parameters, because this would make life so much easier. What I could think of would be a second dump overload which takes a JSON object as parameter which maps preferences like value_separator to values like ", ". What do you think?

[TurpentineDistillery]

Let's forget about this for now; and keep it in mind if the need for more configurability comes up in the future. On that note, here's an article where the author explores various approaches on named parameters in c++ https://marcoarena.wordpress.com/2014/12/16/bring-named-parameters-in-modern-cpp/