Not sure why you validate XML but anyway.
Since JUnit it's just a library and does not produce a report since 2.0 of xunit-plugin, supported JUnit report are those produced by the ant task and maven surefire. My XSD is compatible for both. I validate report in input to reduce possible unexpected parse/transformer (XSLT for not junit report) errors. This make easier resolve bugs because XSD filter out JUnit reports produced by other tools that declare to produce a correct report but they produces custom attributes and some times a different XML structure that could failure in the parser.
Parsing the XML and displaying the statistics is what has to be done by the plugins.
Yes but testsuite attributes meaningful depends from version.
What I wanted to say with At this point why do not add an attribute to mark the differences between flaky failures and failure also in the XML is that when rerun feature was introduced if had been added additional attribute for flaky failures (maybe also an attribute for runs) the XML would be full backward compatible at all because the attributes had the same meaningful of before. Now we have the root testsuite element that declare 10 tests and 2 failures when in real you have only 7 test method (but 10 runs...) and no failures.
<testsuite name="...FooTest" time="0" tests="7" errors="0" skipped="0" failures="0" runs="10" flakyfailures="2">
About the XSD version for what I can see for other software I consider a best practice publish XSD for each version and the XML declare the path to the specific XSD version
<testsuite ... xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report" ... /> (to be compatible with actual)
<testsuite ... xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-2.2.xsd" ... />
<testsuite ... xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-3.0.xsd" ... />
If the change present in 3.0 version, we would have to wait quite long time and there would be a risk that the rerun feature as well as flaky failures are heavily used.
From the point of view of end user if I get an error updating from 2.x to 2.22.1 I have good reason to open a bug. In 3.x thanks to semantic versioning you can answer "we have changed the format". These kind of changes from 2.22.0 to 2.22.1 is much less reasonable, it looks more like a bug.