Having mulled this over for a while, I'm disinclined to go forward with this proposal.  On the one hand, it is a relatively small change, so it doesn't affect the overall complexity much.  However, API design principles suggest that this isn't the right thing to do.

Good APIs tend to steer users towards correct design.  I'm concerned that adding a COMPACT constant will suggest to users that compacting separators in the output is something they should be doing.  Instead, it is a distracting micro-optimization that rarely saves much space but comes at a cost of readability (it is no fun to have to read JSON without spaces).

For other kinds of code generation, minification is normally a post-processing step rather than something incorporated into the generator itself.  When we care about the size of JSON, we really want people to use compression rather than feebly editing-out a few spaces.

The main reason to have the *separators* argument is to factor-out hardwired behavior.  It wasn't really about binary choices: normal-vs-thin, readable-vs-smushed.

Lastly, I don't really like having two-ways-to-do-it.  We already have something that works, so should have we should have a preference for documenting what we have rather than leaning towards continuous slow sprawl with new options that aren't backwards compatible (creating yet another cross-version maintenance issue).