I’m thinking though that a putative manymusl proposal might not be usable in the similar forward-compatible manner as manylinux. Here’s a comment from the creator/maintainer of musl about ABI compatibility, and how musl is taking a slightly different path than glibc (ABI stability is guaranteed, but that’s not the same as “guaranteed it will work”)
This is different from the glibc approach, which is to use symbol
versioning to attempt to retain “bug-compatibility” with the version
of glibc the application was linked with. Such a system forces new
application binaries that want to be able to run on systems with old
glibc to link against the old glibc, and thereby get the buggy
behaviors even if they’re running on a system without the bugs. Myself
and most of the musl community I’m aware of consider this entirely
unreasonable, and that’s why musl doesn’t do it.