Don't think that I just naturally perfectly segment these commits when creating the feature. I heavily rebase and edit the commits before creating a PR.

Pull requests are quite welcome, and should target the next branch.

The increment-after-release model makes sense for branching too. Suppose you have a mainline development branch, and you create maintenance branches for releases. The moment you create your release branch, your development branch is no longer linked to that release's version number. The development branch contains code that is part of the next release, so the version should reflect that.

Remove the commit from step 2. We will merge ignoring the failure. Remove the commit from the other, check it passes with the other commit now on main. Merge the other. We will trigger builds for the main branch of affected repositories to check if everything is in order. Steps 5-8 should happen continuously (e.g. one after another but within a short timespan) so that we don't leave a broken main around. It is important to triage that build process and revert if necessary.

We don’t use merge commits.

But in general the guideline is: code should be clean, history should be realistic.

many organizations end up with messy workflows, or overly complex ones.

If you push to a public branch you shouldn't rebase it since that makes it hard to follow what you're improving, what the test results were, and it breaks cherrypicking