We’re almost entirely limited by what is available in the Python standard library, which afaik pretty much limits us to gzip, deflate, bzip, and lzma. Unfortunately Python does not make any of them mandatory (the related compression will just be unavailable at runtime) so diversifying what compression algorithms we use, means that we place additional constraints on the Python environment.
The current situation is since we’ve standardized around deflate (via zip files) and gzip’d tarballs our only constraint we place on a Python environment is it had to have been linked with zlib which is an incredibly common dependency to have available, even in docker containers, etc.
The other constraint here is that currently we still support Python 2 (at least to some degree) which rules out LZMA since that wasn’t available in Python 2 (unless we decide that this hypothetical new wheel format should only be available for Python 3 or we decide to say that people have to install some LZMA backport to install from wheel on Python 2.
Beyond that I see two real options for how the format would look like, either we do something similiar to conda where we have a tarball within a zip file, where the tarball is compressed with some specific compression scheme. The other is to just use either the zip file support for a different compression algorithm or a non gzip tarball (xz or bzip2 or wahtever).
Honestly, I think either one is perfectly fine, and would probably suggest that the decision would largely be driven by what the compressed size looked like between the two options on real world examples. There is an argument to be had that the metadata could/should continue to be just normal zip members (e.g. not in an inner tarball) to enable easier introspection without having to extract multiple levels of artifact formats.