As Alan Perlis, Rich Hickey and many others have noted, having more
procedures does not make the system more complex. It's only procedures
that have to interact with each other that add complexity. The pretty
printer can be separate from the writer (naturally the implementations
would share many internals).
Having more procedures doesn't add complexity, but having more *exported* procedures does. Each one is another attack surface for penetration testing, another bit of documentation, another item to master in order to master the API. I have in general gone much further in this direction, following Olin Shivers's SRFI 1, than many people think I should have.
You made a good case for write-json-sequence-text (it's verbose, but I think we need the word "sequence" in there) and for write-json-line (see below for more). I am less convinced about json-prettyprint. It's a lot more code, more things to go wrong. "The most efficient, the fastest, the easiest to read, and the most secure code is that which does not exist." If you are convinced that this is something that everyone needs, then make that case. In my view, json-read plus Scheme pp is sufficient.
But if `json-write` writes a condensed format like Scheme `write`, is it
much different from a `json-write-line` that would write a JSON Lines
compatible value? Would there in fact be any difference other than a
final newline?
There would not, but having a separate convenience procedure makes sense because you can be sure that when you call it the output is conforming (this is your own argument). Another possibility is to always write out a trailing newline in all cases, and then json-write would be inherently JSON Lines conformant as well as guaranteeing read-write consistency. Scheme write actually does not quite guarantee it: (write 3) (write 4) (rewind) (read) => 34.