Two more observations:

* Serialization-json-40:

Wouldn't "\t\n\r" be a valid result as well? Next, RFC7159 allows the character sequence in escaped characters to be upper or lower case, so I would recommend to use the following regex:

  \\u(0009|t)\\n\\u(000D|000d|r)
 
* Serialization-json-55:

I believe that the output ["
","\r"] would also be correct. A more flexible pattern could look as follows:

  \["&(#13|D|d);","\\u(000D|000d|r)"\]

Here is Serialization-json-31:

<test-case name="Serialization-json-31">
   <description>Test the JSON serialization output method - normalization form </description>
   <created by="Josh Spiegel" on="2014-11-02"/>
   <dependency type="spec" value="XQ31+"/>
   <test><![CDATA[

     declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization";
     declare option output:method "json";
     declare option output:normalization-form "NFC";
        
     "suc&#807;on"

   ]]></test>
   <result>
     <serialization-matches>"su&#231;on"</serialization-matches>
   </result>
</test-case>   

I don't understand how this expression you give relates to this test:

   normalize-unicode('suc&#807;on', 'NFC') = '&#231;'

Did you mean this expression?

   normalize-unicode('suc&#807;on','NFC') = 'su&#231;on'

I think this should evaluate to true.  

Can you clarify?

Josh, thanks for the clarification and sorry for taking your time. After a second check, I can only agree that the normalization makes complete sense. So all that's left is the two other test cases on serializing 	 and 
.

As I understand it, you would like the test suite to (1) allow lower case and upper case escape sequences and (2) allow \r or \u000D

On (2) the specification currently says:

"If the JSON output method is selected, replace " with \" and the newline character (
) with \n."

It doesn't mention \r.  I think it should.

If you agree, then I think you should file a bug against the specification asking for clarification.  You could re-purpose this bug but it may be confusing that bug comment is unrelated.

I have just file the new bug 27478.

Based on the decision of Bug 27478, the allowed results should now be as follows:

* Serialization-json-40
  "\t\n\r "

* Serialization-json-55
  Three possible results:
  - ["
","\r"],
  - ["
","\r"]
  - ["
","\r"]

Fix applied to the test cases Serialization-json-40 and Serialization-json-55

Thanks for the fixes, O'Neil. Just one more thing. I think the special character need to be escaped:

* Serialization-json-40

  <serialization-matches>\\t\\n\\r </serialization-matches>

* Serialization-json-55

  <serialization-matches>\["&amp;#13;","\\r"\]</serialization-matches>
  <serialization-matches>\["&amp;#xD;","\\r"\]</serialization-matches>
  <serialization-matches>\["&amp;#xd;","\\r"\]</serialization-matches>

Fixed according to comment #8: Escaped special characters