>> what if there are 500 subtests in a loop and you don't want 500 failures to be
>> registered for that test case?
>
> Parametered tests have the same issue. In this case you simply don't use subtests
> or test cases.

Right, but then you lose out on both of the benefits documented for subtests:

+Without using a subtest, execution would stop after the first failure,
+and the error would be less easy to diagnose because the value of ``i``
+wouldn't be displayed::

Why tie these together?  I'm suggesting that we expose a way to benefit from the "easy to diagnose" portion without the "suspend stoppage" portion.  (The way we do this doesn't have to be one of the ways I'm suggesting, though I've suggested a few.)

>> addMessage was just one suggestion.
>
> It is quite orthogonal, actually, and could be added independently. Also, it is not clear how you would limit the addMessage to a subtest, rather than the whole test case.

It's not orthogonal because the way I suggested it, subTest() would be the composition of addMessage() and continueTest() context managers.  (addMessage limits itself by being a context manager just like subTest.)  So if we added addMessage() later, we would want to refactor subTest() to be using it.  The equivalence would be something like the following:

    with self.subTest(msg=msg, i=i):
        self.assertEqual(i % 2, 0)

    with self.continueTest():
        with self.addMessage(msg, i=i):
            self.assertEqual(i % 2, 0)

However, since it looks like we're going with changing the test case ID instead of putting the extra data only in the exception message (TestCase.longMessage) like I was suggesting before, I think adding a failFast=True or maxFailures=n parameter to subTest() has higher importance, e.g.

    with self.subTest(msg=msg, maxFailures=1, i=i):
        self.assertEqual(i % 2, 0)