I think the discussion for the base image of 2_28 showed that it’s good to stay based on RHEL and its derivatives (if only already for the devtoolset backports!). They should all be ABI-compatible anyway, though there’s slight variations (see OP of that discussion). Provided that rhubi 9 comes with a current devtoolset, I think that would be the most attractive option.
It would also continue the pattern so far:
| manylinux | glibc | RHEL |
|---|---|---|
| manylinux1 | 2.5 | 5 |
| manylinux2010 | 2.12 | 6 |
| manylinux2014 | 2.17 | 7 |
| manylinux_2_28 | 2.28 | 8 |
| manylinux_2_34 | 2.34 | 9 |
There’s a pretty large glibc-gap between RHEL 7 & 8, but the debian-based 2_24 was struggling with adoption particularly due to the lack of modern compilers, and is almost EOL, so I’m not counting it.
All that being said, I think there’s really no rush for this. The motivating/constraining factor here is not CI usage, but how many users have a new enough glibc (& pip) to consume manylinux_2_34 wheels. The answer is about 10% of python 3.10 users, and microscopic amounts of all other python users. That is not a reasonable user base (currently) to justify the maintenance effort for most projects to publish such wheels (in constrast, glibc 2.28+ is quite-to-very widespread for everything but python 3.7, which is starting to drop off the radar anyway, cf. e.g. NEP29).