I think then this is where the core of the difference in judgements lies.
Here’s a filter to just the docs changes from your original PR — just the .txt files.
Throughout the ecosystem, everything I’ve ever read, everywhere, no longer corresponds to what I find in the docs. Even if we keep the old API alive as aliases, I think we’re seriously understating the amount of disruption that’s going to cause.
As folks deeply vested in Django, we hear a suggestion like this, and think Ooh, yes, that would be good, but most of our users aren’t so closely involved.
To then say we’ll just change the documented API without further benefit is (if you have your finger on the merge button) slightly eye-watering. It’s nicer yes. It’s hard to see whether it merits the cost in the wider user-space though. We’ve done massively well keeping Django stable whilst progressing it. Stability is arguably our USP — that’s what folks rely on.
If, in contrast, though, we’re able to offer a new set of capacities on HttpRequest, then there’s a story to tell. There’s this new API, and look what it gives you. (If it’s just aliases, wouldn’t a ModerniseRequestMiddleware do in the meantime?) OK, disruption, but it’s worth it.
(Or so goes the line of reasoning.)
I’ll let others comment, since you’ve invoked the powers 