The specialized use case is wanting to autogenerate a name with no other information provided.  You suggested csv as one example where this would be used, but even in that case I'd rather see something based on the filename than a mashup of field names.  I would also personally rather see '_' than a long string of field names (it would make the debug output prettier because the lines would be shorter).

In contrast, being able to specify a name satisfies a wide variety of use cases, including that of autogenerating names with no other information provided.  Which is why that is included in the API.

I hear you about the rename logic.  But for myself, since I don't like the idea of the name being a mashup of the field names, it isn't convincing :)

I wrote a "parameterized tests" extension for unittest, and it has the option of autogenerating the test name from the parameter names and values.  I've never used that feature, and I am considering ripping it out before I release the package, to simplify the code.  If I do I might replace it with a hook for generating the test name so that the user can choose their own auto-naming scheme.

Perhaps that would be an option here: a hook for generating the name, that would be called where you want your None processing to be?  That would not be simpler than your proposal, but it would be more general (satisfy more use cases) and might be worth the cost.  On the other hand, other developers might not like the API bloat ;)