I'd love to see a technical writeup of the differences. If Rocky genuinely were better, a 5-week delay vs Alma would probably be ok, at least for the original release, as long as the dot releases are faster. No one wants security vulnerabilities delayed by 5 weeks.

This is not correct. The issue is trying to use Alma 8’s mock chroot on a CentOS 7 host. The (older) versions of yum and rpm there don’t support subkeys.

There is a Red Hat BZ issue here: https://bugzilla.redhat.com/show_bug.cgi?id=2017069

Do RHEL/Rocky/CentOS Stream 8's mock chroots work on CentOS 7 hosts? If so, then this does seem like a legitimate binary incompatibility.

That is not what binary compatibility means when talking about RHEL. It refers to the actual package ABIs and the compatibility levels we assign them:

https://access.redhat.com/articles/rhel-abi-compatibility

https://access.redhat.com/articles/rhel8-abi-compatibility

https://access.redhat.com/articles/rhel9-abi-compatibility

This would be closer to a bug-for-bug compatibility issue, as a result of an implementation change on the infra side of things. It's not due to the OS which is bug-for-bug compatible with its origin, RHEL 8.

While it would be nice if EL7 stacks are considered by the rebuild distributions, it's not a requirement and they are free to use features supported by the platforms they're building.

Well, I can do a mock -r almalinux-8-x86_64 bootstrap build on RHEL7. (I can't remember whether there are currently any problems maintaining for RHEL8 on RHEL7, but it has been impossible to maintain packages for RHEL N+1 on RHEL N in the past. I just moved to a RHEL8 VM rather than prat about with 7 more.)