I understand RFC 7159 as follows: JSON is a text format made of Unicode characters, encoded in UTF-8 or UTF-16 or UTF-32. So, data that is not valid UTF-8, UTF-16 or UTF-32 cannot be JSON.

While it may make sense for a parser to convert invalid sequences into U+FFFD, this conversion is not a Unicode requirement, that's why I think that a strict JSON validator should reject invalid UTF-8. I'm all willing to be convinced by another interpretation :-)

Meanwhile, the tests have to be consistent, and it seems they are not.

Unicode allows parsers to either reject ill-formed input, or to replace ill-formed input with U+FFFD. It's very common to pick the latter approach. JSON operates on Unicode text, so while it's correct for a JSON parser to reject ill-formed input, it's also correct for a JSON parser to replace ill-formed input with U+FFFD. I think it's valuable to have tests in the test suite for this to ensure that the parser doesn't crash, but the tests should be considered implementation-defined as the parser can legitimately choose either option.