> JSON Sequence is https://tools.ietf.org/html/rfc7464

Good catch.

>> In JSON Sequence, you are guaranteed that every JSON value has a specific start (U+001E) and end (LF) character, and it is guaranteed that the start character can't appear in the JSON representation, because control characters in JSON strings have to be \U-encoded.
>>
>> In JSON Lines, it is guaranteed that the end character doesn't appear within the JSON representation either, so no start character is needed.
>>
>> Both are robust against incomplete JSON representations.  They are also robust against accidentally adjacent values (just writing 3 and then 4 will be reread as 34 otherwise).  Unfortunately a single doc can't conform to both because a Json Lines processor will break on reading the U+001E.

Since JSON, JSON Lines and JSON Sequences are different standards, I
propose having separate write procedures for each:

- json-write
- json-write-line
- json-write-text (is this a good name? "text" is the term the RFC uses)

That way it's easy to verify that your code writes JSON conforming to
the standard you intend. If these standards are an optional or keyword
argument for the normal json-write procedure, or come from an options
struct, it may be easier to forget them.

Forgetting options isn't as serious for something like how much
indentation you want to use, but since these standards are designed for
strict interoperability, it's important not to break their syntax.