At first blush the sounds like a very reasonable analysis, Martin. Strikes me as difficult, but probably possible, to automate the idea that Test2/ runs (by default) on both tei:current and on tei:current-1. The driver script would have to look in http://www.tei-c.org/Vault/P5/ and have some heuristics to determine the latest and latest minus one releases, then run all the tests twice, once for each. (This behavior should, of course, be something that could be overridden at the commandline so you can run the tests against any version you want.)
I've been thinking about the circular dependency thing. What it basically means is that any given version of the Stylesheets MUST be functional for both the previous version of P5 (as released on the site) and the next version of P5 (in the dev branch, or ultimately in the master branch at release time).
As long as we're clear on that, we can set up Jenkins build processes that test it. And if we ensure that's the case, then we can make a point of releasing the new Stylesheets version ahead of the P5 version, maybe a day or two before, so that we're not trying to do both at the same time.
The only potential problem would be a situation in which a change in P5 requires a corresponding change in the Stylesheets that breaks backward compatibility. But that would surely be a bad thing anyway; we should be coding explicitly to support both old and new TEI structures in the Stylesheets.