well, I have ideas that are varying degrees of radical 😅 there are lots of ways we could get rid of the manual merge conflict resolution dance but the one that would streamline the -next rebuild avoidance dance looks like:

we only have one true branch (per release), master, and we conditionalize big rebuilds with feature flags conditionals like version = if ... stage... then "3.0" else "2.1";. preparing a new -next is just increasing the "epoch" past all currently staged changes. (could also make it a bit easier for us to say "uh, big security fix, let's roll a cycle without this risky stuff")

to do clean-up and reduce the tedium of authoring changes, we have a script that automatically adds these conditionals in a separate commit on top of your "staging-based" commit. merge queue checks you didn't break eval on any epoch and that the staging commits don't cause rebuilds at the relevant epoch. then -next/staging branches just undo those staging commits so you have base for changes and we merge them in for clean-up once a cycle completes. you only have to do manual "conflict resolution" when there's a genuine divergence between the branches and the script can't automatically do it, and it happens in the relevant PRs.

so here you'd add the patch, the script would add the conditionals, and staging vs. -next would just be a question of what epoch you assign it to. you can always see from master when there's changes in-flight, and clean-up happens automatically

should probably conditionalize and revert on staging

Conditionalized.

[git PR] should probably conditionalize and revert on staging

Conditionalized.

there's a lower-tech variant where you have no conditionals in the code but every staging/-next PR has a HEAD that merges it back into master to undo the changes, and merge queue just validates no conflicts/eval errors across the branches. that makes merging -next into master weird from a Git POV though (it would produce a nop by default because "all the changes are already merged in").

or the reverse is that if you have to do something to resolve conflicts between master and staging/-next you keep your commit based on master but add a merge commit merging it into staging/-next and the master portion of it just gets automatically backported.

those avoid any eval time machinery but abandon the property that there's one canonical tree that lets you see when stuff is in flight before you touch it. they would also interact a bit weird with the way GitHub displays merge commits and require CI to have more smarts around them