I think I have figured out what bothers me about the expectedfailure changes, and they actually relate to how expectedfailure was implemented in the first place: I had previously assumed that decorator was an *annotating* decorator - that it set an attribute on the function to indicate it was expected to fail, and the test execution machinery then took that into account when deciding how to interpret the test result.

The fact that it is instead a *wrapping* decorator is what made the addition of subtest support far more complicated than I expected.

However, I'm wondering if it might still be possible to avoid the need for a thread local context to handle the combination of expected failures and subtests when we have access to the test caseby adding the annotation that I expected to be there in the first place. Can't we:

1. Update the expectedfailure decorator to also set "_expecting_failure = True" on the wrapped test case function
2. Update unittest.TestCase.__init__ to do: "self._expecting_failure = hasattr(testMethod, '__func__') and getattr(testMethod.__func__, '_expecting_failure', False)"
3. Update unittest._SubTest.__init__ to do: "self._expecting_failure = test_case._expecting_failure"
4. Update testPartExecutor to check "if test_case._expecting_failure:" instead of the current check of the thread local context