In my case I've been doing PEP 399 for collections.OrderedDict.  It struck me that the boilerplate could be stowed away in a decorator.  It's more than just adding a couple subclasses.  Here's what it covers:

* add the test case subclasses,
* make sure the original test case does not get used (#16835),
* use the relevant names as class attributes rather than globals (e.g. self.OrderedDict vs. OrderedDict),
* hack around modules that do their own imports (#16817),
* others(?).

When adapting existing test cases having a decorator to do this makes the job a snap without having to worry about corner cases.  You have to add the decorator and then add the new test names to the test discovery code (at least until we use unittest's test discovery).  For new test cases and splitting out test cases it likewise simplifies things.  On top of that, if you drop the decorator the test case would still run as-is.

Other benefits for both new and existing test cases:

* the decorator makes it clear what is going on (or will be made to) via the decorator name,
* the requisite boilerplate doesn't have to clutter up the code,
* when something like #16817 or #16835 comes up, it's much easier to update the decorator in test.support instead of finding each of the PEP-399-ized tests that is affected and updating them individually.

Downsides:

* "explicit is better than implicit",
* relatedly, the solution is more magic/obfuscated that the current boilerplate.

You could argue that the magnitude of the problem doesn't warrant a complex decorator, but it doesn't have to be hard to understand.  My patch is something I threw together late last night that could certainly be made more clear.  More importantly, as more modules get a dual implementation, the above benefits of the decorator become more pronounced.