After thinking about this more, it seems this lets you do two orthogonal things:

1. Easily append data to failure messages coming from a block of asserts
2. Continue running a test case after a failure from a block of asserts

Both of these seem independently useful and more generally applicable, so it seems worth discussing them in isolation before exposing them only together.  Maybe there is a nice API or combination of API's that lets you do one or the other or both.

Also, for (1) above, I'm wondering about the choice to put the extra data in the id/shortDescription of a pseudo-TestCase instead of just adding it to the exception message, for example.  Adding it to the message seems more consistent with unittest's current API.  Including the info in a new name/id seems potentially to be misusing the concept of TestCase because the test names created from this API need not be unique, and the resulting tests are not addressable/runnable.

Incidentally, I noticed that the runnability of TestCases was removed from the documentation in an unreviewed change shortly after the last patch was posted:

-An instance of a :class:`TestCase`\ -derived class is an object that can
-completely run a single test method, together with optional set-up and tidy-up
-code.

(from http://hg.python.org/cpython/rev/d1e6a48dfb0d#l1.111 )

whereas subtest TestCases from the last patch are not runnable:

+class _SubTest(TestCase):
+    ...
+    def runTest(self):
+        raise NotImplementedError("subtests cannot be run directly")

A way around these issues would be to pass the original, runnable TestCase object to TestResult.errors, etc. instead of a pseudo-TestCase.  Alternatively, subtests could be made independently addressable and runnable, but that route seems more challenging and less certain.