I’m not a SC member, but the impression I got from the previous PEP 594 discussion and SC comments surrounding it was that as the modules are no longer supported by the CPython and the Python core developers, it should be up to the community to self-organize and maintain one or more PyPI versions of the module in question if there’s sufficient interest in doing so, and the SC/core dev team needn’t and shouldn’t be officially involved. For example, it was initially part of the PEP proposal to maintain a separate official repo for the deprecated modules (as some suggested here), but that was later rejected. It seems to me that formally appointing a new maintainer to control the name would invoke similar concerns.
And in any case, that involves essentially the same issues as described above (having to pick a winner, confusion over whether the package is “official” or supported by the core team, long term security and maintenance implications, accidental installations, etc) for putting the PyPI admins in that position, just with the SC in its place. By contrast, it seems to me that can be avoided by just keeping the names reserved, and letting the community interested in and responsible for the old module sort things out.
@brettcannon , as both a SC member and the current author of PEP 594, and also involved in discussions concerning the stdlib’s future, we’d love to hear your thoughts here!