> 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,

I don't understand what you mean. 1 is pointless without 2 (if you let the exception bubble up, unittest already deals with it). 2 without 1 doesn't make much sense either (if you only want to silence an exception, a simple try...except will suffice).

> 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.

If e.g. someone lists all failed tests without detailing the exception messages, it's better if subtests are disambiguished in that list.

Also, changing the exception message might be confusing as readers expect the displayed message to be exactly str(exc).

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

runTest() is still mentioned in the TestCase constructor:
http://docs.python.org/dev/library/unittest.html#unittest.TestCase

but indeed it was removed from the module overview, because it doesn't 
correspond to modern unit testing practices. I guess it could still be covered in the API docs.

> Alternatively, subtests could be made independently addressable and
> runnable, but that route seems more challenging and less certain.

I would say impossible, unless you know a way to run a `with` block in isolation ;-)