The spec of json-doc says:

If the resource contains characters that are not valid in the version of XML used by the processor, then rather than raising an error as fn:unparsed-text#1 does, the function replaces such characters by the equivalent JSON escape sequence prior to parsing.

The mechanism of "replacing such characters by the equivalent JSON escape sequence" does not achieve the required effect (unless you adopt a generous interpretation of "equivalent"). There are many places where an escape sequence is not accepted in the JSON grammar - though such cases aren't really a problem because the only effect is to change an error at the encoding level to the an error at the JSON parsing level. But there are some places, notably after "\", where inserting an escape sequence changes the meaning. For example "\" followed by x00 should be an error, but "\\u0000` is a legitimate representation of the six characters \ u 0 0 0 0.

Some of the new JSON test cases in test set misc-JsonTestSuite, adapted from http://github.com/nst/JSONTestSuite, illustrate these issues.