I spoke with Hood about this at PyCon. I’d love to see this move forward. The externally hosted definition of the platform is linked from the PEP, and there’s a PR waiting in the packaging repo. cibuildwheel’s been able to build these for a long time now.
One thing I think helps is considering the future of the platform. Having a tag for an implementation is common; PyPy and GraalPy are some examples. However, the interesting thing here is that if CPython support progresses to Tier 2 (it’s not even back up to tier 3 yet, this is forward thinking), then CPython will want to have a defined Emscripten platform tag (likely identical to the pyodide one). I think that’s completely fine; either the source of the pyodide tag definition moves to CPython, or a new tag can be introduced - if they become synonyms, that’s similar to what happened with manylinux_2*.
I think this comparison between manylinux and emscripten is a good one, actually, though they are different. A “linux” wheel works on just the system it was generated on, much like an emscripten wheel. Tagging it with manylinux means it is ensured to work on a larger set of Linuxes, while tagging an emscripten wheel with pyodide means it was generated with a specific emscripten version and set of ABI flags to work on Pyodide or any build of Python with matching flags. From a distribution standpoint, this is nearly identical; you have a way to describe specific wheels you build locally and only work on a specific system, and a way to describe wheels that are suitable for distribution and work with an ecosystem.