First of all, I agree that the API for import_fresh_module() isn't ideal and could stand some improvement.  I've created issue 17146 for pursuing that avenue.

More importantly for this issue, simplifying import_fresh_module() is not nearly enough of a win for me regarding PEP 399.  My big motivator here was to make complying with PEP 399 much easier.  That encompasses more than eliminating the extra call to import_fresh_module().

There are a number of considerations that I've already outlined, which especially relate to maintenance and writing new dual-implementation tests.  Without a comprehensive helper, existing tests don't automatically benefit from a better way of doing it (or fixes); converting existing tests to dual-implementation isn't as simple; and when someone goes to write new dual-implementation tests they have to do all the boilerplate and cover the corner cases (e.g. pickle-related tests).

I'm coming at this from the perspective of someone who hadn't already written or adjusted tests to accommodate PEP 399.  Having a more comprehensive helper would have saved me the time to figure it out, which I count as somewhat wasted since it's just boilerplate.  I'd rather be working on the tests and the code that I'm testing.  I'd rather not ask anyone else to take the time to get familiar with the boilerplate when I'm sure they'd rather be working on their problem than shaving this yak. :)

For the record, I'm glad we have PEP 399 and that we are making the effort to get more pure Python modules in the stdlib.  A big thanks to Brett for continuing to push for this!

Ezio, I'm on board with your summary, though I'm +1 on adding the helper. :)  I didn't have any plans to refactor any tests, but I would like to use any helper that might come out of this discussion in my testing of OrderedDict.