That all sounds good to me Nick. Some notes / questions.

How should parameterised tests be marked? I'm happy with a unittest.parameterized decorator (it would do no work other than mark the test method, with the parameterisation being done in the TestLoader).

What could the "name customisation hook" look like? A module level hook (yuck) / a class method hook on the TestCase that must handle every parameterised test on that TestCase / a decorator for the parameterised test method?

If we do it at load time should we require parameterised methods to be class methods? The alternative is to instantiate the test case when loading and collecting the tests. Class methods won't play well with the other unittest decorators as you can't attach attributes to classmethods. (So I guess instance methods it is!)

If collecting tests fails part way through we should generate a failing test that reports the exception. Should the tests collected "so far" be kept?

Should skip / expectedFail decorators still work with them? If so they'll need custom support I expect.

If we're generating test names and then attaching these tests to TestCase instances (so that normal test case execution will run them), should we check for name clashes? What should we do if there is a name clash? (The generated name would shadow an existing name.) We could prevent that by using a non-identifier name - e.g. "${}_{}".format(name, idx)