“I'm basically giving myself a permanent vacation from being BDFL”

Guido's question gets to the heart of the problem:

"So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?"

No. None of the above. These are mechanisms which make choices when a choice must be made, even if none of the options is broadly acceptable. An appropriate mechanism for, say, governing a country.

Python isn't a country, it's just a programming language, so when there aren't any popular options _doing nothing_ is always the backstop. Does that mean that maybe, eventually, your programming language will shrivel away and become irrelevant? Yeah, it does. But again, not a country, just a programming language, use a different one.

Rough consensus is what you need here. PEP 572 never had rough consensus. Could it have obtained such consensus, someday, perhaps, with more work? Maybe, though I doubt it. But it didn't have that when the PEP was rammed through by the Benevolent Dictator.

Who decides when there's rough consensus or broad acceptance for a change? You have a bunch of people with commit access to the python repository; of course you need some mechanism to decide what goes in.

Rough consensus is what you need here.

Why?

Consensus approaches are terrible ways to design languages. It's why Java took so long to evolve, where C# rapidly adapted to changing needs; and why C++ lingered in a long state of crappiness until Stroustroup came back and is now pushing improvements every three years.

Languages generally do well when there is a sense of leadership and vision for where it is going. Consensus is terrible at providing both.

A rough consensus is trivially observable. Look around. Who's left saying that plan Foo is a bad idea? Just that one guy who is a total crank and thinks Python shouldn't support 64-bit processors? Nobody cares about him. How about people who think plan Foo is a good idea? Basically everybody who talked about it other than the crank: OK, that's rough consensus.

If you have situations where your "bunch of people with commit access" aren't sure if there's consensus then you don't have a consensus.

As to why you need it: Because unlike countries people have a real choice. All your language users are volunteers. (No "Seasteading" and "Freemen on the land" are not real choices). Not only can they freely choose another language instead of Python, they can fork Python and go make their own instead, or maintain the current code frozen in perpetuity.

Now, if there really is a 50:50 split between people who must have feature X and people who'll leave if feature X is added to Python, nothing you can do will solve that. So it's wrong to try to design your structures for that problem. More often there is a third way, and consensus helps you to be sure you found the third way.

What if the core committers are generally decided for A but the language users at large are for B? The way you make those decisions is a mechanism, even if you don't want to name it.

In the scenario you describe there sounds like no consensus for A or B.

Maybe, after they explain how great A is the core committers can bring the language users around on the idea of doing A. Maybe after spending more time considering why B is beloved of language users the core committers come around to B.

Perhaps most likely if the two conflict is that C is developed as both sides look for the best of both, what an excellent outcome.

And if not, then do neither A nor B

We regret our bad ideas at leisure. No need to bake those bad ideas into a programming language just because of a vague feeling that "we must do something" (and as the saying goes "this is something, so we must do this").