> I do respect the beta feature freeze. The relevant feature was added prior to b1. The reverted change is an incremental fix addressing underlying implementation details such as how resources are resolved and removing duplicate code paths.

Using the revert hammer is never an easy call and I've only done that a handful times so far. In this particular case the following helped me make the decision:
- the change was over 2,000 lines big;
- as you say, a non-trivial amount of it was refactoring;
- the change was committed without review;
- the backport was done three weeks after the beta freeze without consulting the RM or anybody else in that matter.

Sure, it's worth fixing the problems you identified after Beta 1, maybe even bring the fixes back to 3.9, but not how this was done this time. We'd like to keep our release cadence stable and avoid hotfixes in the future.

We are all grateful for your work, Jason, and we're happy to have somebody around who is invested in making Python better. To reiterate, I'm less worried about the introduced bug itself, and more about the change management attitude. Yes, it would indeed be a shame if your feature had to wait for another Python release. But risking widespread breakage isn't a good trade off.

It sucks for me to be this boring beaurocrat, believe me, but the purest solution to a deep design issue identified after Beta 1 in a new feature is to... revert that feature altogether and go back to the drawing board for the next release. It's not a theoretical situation. I went through this in the Python 3.8 cycle (see BPO-38242). It sucked but it was the right thing to do.