> I am concerned that this feature changes the TestResult API in a backwards incompatible way.

My suggestion to add the original TestCase object to TestResult.errors, etc. instead and add the extra failure data to the longDescription would address this concern, which is why I suggested it.  The former is what currently happens with multiple failures per TestCase (e.g. in runTest() and tearDown()).

> The underlying idea of subtests is "if you want to parameterize a test,
here is a useful building block".

The current API doesn't seem like a good building block because it bundles orthogonal features (i.e. to add loop failure data to a block of asserts you have to use the continuance feature).  Why not expose *those* as the building blocks?  The API can be something like--

    with self.addMessage(msg):
        # Add msg to the longDescription of any assertion failure within.
    
    with self.continueTest(msg=''):
        # Keep running the TestCase on any assertion failure within.

(The current subTest() is basically equivalent to continueTest() with a specialized message.  It could be added, too, if desired.)  Accepting a string message is more basic and flexible than allowing only a **kwargs dict, which seems a bit "cute" and specialized to me.