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