Problem/Motivation
During the Drupal 9.5.x cycle, we tried to defer as many issues with deprecations as possible to 10.1, this meant quite a lot of issues were delayed from landing.
I don't think we should do that this time, but we also don't want to create too much of a moving target for contrib compatibility.
On the other hand, we don't want loads of 'best effort' deprecations like constructor arguments to sit around for years.
Steps to reproduce
Proposed resolution
If a deprecation is for @internal code like constructors or plugins, continue to deprecate for removal in 11.x
If a deprecation is for base classes, interfaces, or otherwise likely to affect a lot of modules, deprecate for removal in 12.x
Module/Theme deprecations are allowed - it's actually easier to do these at the end of a major release cycle than earlier on, and while they're slightly disruptive for sites when they update, they're generally not disruptive for contrib or custom modules since the API of the deprecated module stays the same.
There will be lots of edge cases, we can link examples from this issue.
Remaining tasks
f
