I'd advocate strongly against a compat package.
The whole point of the change is to push the move to the new autoconf upstream release. Not the availability of autoconf 2.71 to the end user. For that, we would do much better with providing the end users with a modular release, I think.
As for the argument of other distributions, Fedora has always been an early adopter. If we will create a compat package providing the 2.69 version, what's the point of moving to autoconf 2.71 (maybe over providing a modular build) anyway?
What I would argue is that we should make an effort to fully move to the new version of autoconf, and postpone the change if we find out that it is not doable in time for F35. Historically, it took some effort to mitigate providing compat packages of autoconf, and experience tells us that when we do, the motivation to fix packages incompatible with the new version virtually disappears.
IMO, the only scenario, where a compat package would make sense, is if we were to push for the removal of this compat package right from the moment of it's introduction. In that case, the only real benefit of completing the Autoconf 2.71 change, would be *a little* easier process of making necessary changes to now incompatible packages in exchange for any real motivation to actually do so. If the point of this change is the availability of autoconf 2.71 to the end-user, I would argue that a modular build would be a much cleaner approach.
We should push for this change to be done the proper way, not for the possibility of making a slow progress over long period of time for the price of duplicating packages. If we need more time for that, this change should be postponed.