It appears that the switch from KXml2Driver to StandardStaxDriver in JENKINS-69129 (included in 2.387.3-rc33338.349f385d65d2 as well as weeklies) broke the ability to round-trip ASCII NUL characters in text. Prior to the change, this character was written as � and (whether correct or not) read back successfully. After the change, it is still written the same way, but cannot be read.

Seems unlikely to affect many users, though it may affect the Jenkins project itself: for example

mvn -pl test surefire:test -Dtest=ExecutorTest#disconnectCause_WithoutTrace -Dmaven.test.redirectTestOutputToFile=true

causes TEST-hudson.model.ExecutorTest.xml to include

<===[JENKINS REMOTING CAPACITY]===>&amp#0;&amp#0;&amp#0;channel started

which looks to be bogus output from Surefire but which does not trigger a problem, whereas hudson.model.ExecutorTest-output.txt contains

<===[JENKINS REMOTING CAPACITY]===>^@^@^@channel started

(with ^@ standing in for actual ASCII NUL for display). In case the NUL makes it into a stdout field in junitResult.xml, the symptom is that the junit step publishes test results normally (setting the build status, sending checks to GitHub, etc.) but if you visit the testReport/ display in the GUI, it claims there are no tests found (after printing a stack trace to the system log about a parse error). Other plugins looking up test results (such as parallel-test-executor) can also be affected.