A) While they are good ideas in SRFI-180 e.g. json-fold, it is clear
the premise is wrong, quoting the abstract:

> It supports JSON that may be bigger than memory.

That is wrong to store very large data in JSON, and I do not want
to promote that practice. More and more people lean toward using
SQLite as an application file format [0].

[0] https://www.sqlite.org/appfileformat.html

B) It seems there is a typo in the public procedure:

  json-number-of-character-limit

`character` is missing an s.

C a) The implementation does the job according to the test suite,
but it seems there is still a few problems as noted in [1]

[1] https://srfi-email.schemers.org/srfi-180/msg/17734800/

C b) The problem of the implementation stems from the premise
that json-read, and json-write should support bigger
than memory, possibly deeply nested datastructures. That
requirement overcomplicates the implementation because I
avoided call/cc.

D) json-fold is fun, but in practice it is very difficult to build
the arguments. The primary goal was to allow to customize the
datastructure container for JSON arrays and objects in _one pass_.
Now I believe that is too complex, in most cases.

I built an alternative library at scheme-live [3a][3b]. It re-use
the SRFI-180 test suite, and is tested with more than 10 Scheme
implementations. Most skipped tests relate to unicode decoding.

[3a] https://github.com/scheme-live/live/blob/hello-schemer/live/json/unstable.sld
[3b] https://github.com/scheme-live/live/blob/hello-schemer/live/json/body.scm