We tried a couple of avenues for finding funding quickly, but none of them panned out. We are going to have to write a grant proposal to someone. Due to other commitments and travel, the earliest we can start on that is going to be November, and I can’t say when the funding will actually materialize.
Having thought about this some more in the interim, though, I now agree with @njs that, if the ultimate solution for mysterious C++-related crashes requires changes to the manylinux specifications, those changes will be orthogonal to the changes from manylinux20xx to perennial, and therefore this outstanding bug should not be a blocker for perennial.
I still think the perennial PEP should be deferred until after the manylinux2014 transition is complete and we have seen all of the fallout from it. “Complete” means something like “more than 66% of all wheels downloaded from production PyPI daily, to Linux, containing compiled code, are manylinux2014 wheels.” This is entirely because of process-related unknown unknowns; I don’t think we can be confident of being able to tell whether perennial is completely specified until we see the manylinux1 → manylinux2014 transition play out in production.