It’s not just about UI on PyPI. Having multiple distribution names for what are really just variant builds of the same distribution is awkward in many ways and does not really reflect what is actually happening.
It’s awkward for project authors to create and upload the variant wheels with different distribution names. It’s confusing for people looking at PyPI or other metadata to figure out what is going on and where the real packages are and which are equivalent. In reality you can only have one variant of each real distribution installed but now some installers might end up attempting to installing conflict ones like python_flint_x86_v2 and python_flint_x86_v3.
It’s awkward to end up needing more names or even an open-ended list of names on PyPI and to maintain secure control of them and to check each of them to see that they have the right files and release versions. If you have 50 cu11 distributions and 50 cu12 distributions then what are you going to have to do when cu13 comes out? Then other indexes that host subsets of PyPI need to add the 50 new names so it’s awkward for indexes and other things as well. You also have a big name squatting surface because someone can come and register cudf-cu13 etc on PyPI.
It also messes up the install from sdist model because if you build from sdist you are going to get one of the build variants but none of the tooling will understand that you have e.g. the cu12 variant. Then after installing bar from sdist you might find that pip install foo installs foo_cu11 or maybe foo_cu11 requires bar_cu11 and then pip tries to install that as well.
Realistically the different build variants are variant builds of a particular distribution corresponding to a particular sdist and an installation can only contain one variant of that distribution. It would be better if we can have the tools understand that fact on a basic level rather than trying to workaround the limitations of the current model with dummy distribution names.
In fact not understanding build variants is already problematic because we implicitly already have build variants e.g. non-portable vs portable PyPI wheels etc. Currently I can build e.g. numpy from source and then pip install scipy from a PyPI wheel and those are not necessarily going to be compatible. Likewise I can conda install numpy and then pip install scipy and that might also be incompatible. A similar situation existed in the past with the Christoph Gohlke’s wheels vs PyPI vs conda. There are already many build variants but we currently have no way to distinguish them and tools like pip just assume that they are all equivalent. If we can make it so that build variants are distinguished then there are other problems that could be solved at the same time.