IMO, as part of this we should consider what kind of additional planned changes depend on the change in question.
Something like ~bool deprecation is relatively easy to revert. But something like changing object memory layout or repurposing an undocumented attribute is very hard to undo when lots of other work already depends on it, and it’s found to conflict with documented behaviour or existing code. For examples see #112743 or hiding allocators.
Somewhat related, I think we should require more design documents – InternalDocs files, PEP, or just code comments/docstrings where appropriate – for private internal details (or what looks like private details), which don’t end up in What’s New.
Reading code is fine, but if the code is wrong or isn’t self-consistent, documenting the intent is invaluable. And prose is easier to scan for people who aren’t deeply involved in the change, but who might notice unwanted interaction with other uses/features.
And on another note, I think that if you see opposition from another core dev, and you can’t convince them to (reluctantly) agree, you should escalate – from a code review snippet to a dedicated issue, from an issue/PR to Discourse, and if there still isn’t consensus, to the SC (with a PEP if it takes more than a paragraph or two to explain). Don’t push a change through if there’s active disagreement.