Consider always having the next major branch open

One way to avoid having two versions of an MR would be to just not require it for the next major commit, so there's still some deprecated code committed in those cases. This would still allow other breaking changes like type hints to go in straight away.

I wan to reiterate this just essentially opens the 'next major' split early, we do so every major release so the process isn't abnormal in that regard. IMHO this tends to align with having a MAIN branch which is intended to eventually be done for core.

Pros:
New API can be implemented immediately.
No need to postpone API breaking change or major system overhauls to branch split (issues can be worked on when devs have the time rather than crushed into a shortened release window)
Ecosystem can begin testing with the new major, as it will exist, much sooner (possibly reducing the number of critical bugs to fix during alpha/beta). This goes beyond just phpstan
Less followup tickets (possibly less cluttered issue queue).

Cons:
An additional branch to maintain.

One way to avoid having two versions of an MR would be to just not require it for the next major commit

Considering we have a fairly standardized deprecation format, It may be possible to work the issues with deprecation and let rector strip them to create the mainline MR. Could be tested and possibly become an "on commit" task if it proves reliable.

Addtionaly a healthy workflow inside MR can make it easier if developers separate deprecation from non deprecation it could be a simple re-base with excluded commits. This would take a bit of training however is reasonable to expect long term we could accomplish this.

We almost somewhat have the work already separated, I frequently see issues get through review to only later get tagged "need deprecation" before the issue can be committed. For those issues it is not much more effort to cherry-pick the current work based on the mainline branch on top of the released branch and add the deprecation.

The major con from my perspective is that the backport policy would mean that bugfixes for the production branch, to say nothing of the maintenance minor branch, would inevitably start taking longer and longer as we approached a new major release. Multiple merge requests would be required, and it would move us away from what I think our primary goal is: Having a well-maintained production branch that is fixed quickly and easily when needed.

I also think it would get to be a real headache for contributors. If we're requiring them to have all the merge requests reading and not just one before commit, maintaining 3, possibly 5 merge requests on an issue, all of them going stale and needing rebases and needing merge requests resolved... that would get quite exhausting. We've realized that even 10.x is not a safe cherry-pick less than a year from the release of Drupal 11, so it does have to be separate merge requests.

fwiw #4 is exactly what I think would happen with this, and I think we do a decent if imperfect job of informing modules about deprecations for the new major.