One use case is to serve as a staging site for production PyPI to test changes before they go to live. If I had to pick any use case as it’s “core” use case, it would be this one, it’s currently optimized for it and we’re unlikely to make changes that deviate from it. Unfortunately it’s not really good at this because staging sites are generally not a great way to prevent regression (versus something like automated testing), so with Warehouse TestPyPI is no longer a staging site for the production code, and they are deployed at the same time.

Another use case is the one you specified, someone wants to test their releases prior to uploading to the “real” PyPI. TestPyPI is not great at this use case both because, as you noted, it has the same “you can only upload a file once” semantics as PyPI does, but also because it doesn’t have a full copy of everything on PyPI (and worse, it potentially has broken or insecure or malicious versions of your dependencies) so pip might either be blatantly broken OR produce subtly broken installs. Long term the solution that I believe has merit for this, is the ability to, on regular PyPI, “stage” an upload to a temporary location that would automatically be deleted after some period of time, and that once you were satisfied with it, could be published/committed and thus be available to normal ``pip install`` invocations. This not only would allow testing a release beforehand, but it would also allow projects that produce many different artifacts across a variety of platforms to collect them all and upload them and make them all available immediately instead of one at a time. You can see more about this idea/use case at https://github.com/pypa/warehouse/issues/726.

The third relevant use case of PyPI is people simply messing around or doing testing of a generalized workflow tool but not specific to a specific package. This could also include people who are learning how to produce a package, but using a trivial throw away project (the infamous printer of nested lists is an example of this). TestPyPI can be used for this as well, but again it’s not really good at it. The key difference here is that ideally these projects are either ephemeral or namespaced to the specific user. I don’t have a great idea for how best to handle this, the immediate thought is a secondary deployment of Warehouse (such as what TestPyPI is now), that just periodically and automatically purges any projects > N days old to give it a more of a “sandbox” vibe and use case. Given the aforementioned staging feature, we would likely otherwise keep the same ruleset as exists on the production PyPI (and ideally, we’d be re-using credentials too, instead of it literally being a complete secondary deployment). That idea isn’t set in stone and I haven’t done a lot of thinking about it yet, but discussion of that particular use case and ideas to fix it would take place in https://github.com/pypa/warehouse/issues/2286.