I'm curious -- how many of the people who want v3.3 instead of stable expect that they would actually interact with this branch, checking it out and supplying merge requests, versus just thinking it's better in some ideal fashion?
i think our mental model of version tracking is different.
imagine this scenario (that, IIUYC, you explicitly stated that you don't want to support):
- v4.0 is released, but it contains refactorings that require non-trivial efforts from users and implementations to integrate. - main holds quite a few shady/untested commits that will eventually become v4.1 (by forking off of main at a future point in time, then doing some testing/fixing in the release branch, and then eventually tagging its head as v4.1.0, then repeat and tag v4.1.1, etc). - v3.4 is the latest release in the v3.x line, which most implementations are still shipping with. - along comes a bugfix at this point in time, that you commit into main.
let's assume that you want to support both camps; i.e. the late adopters, by cherry picking the fix from main into the v3.4 branch, and releasing v3.4.n+1. and you also want to support the early adopters by cherry picking the fix into the v4.0 branch from main. if you're lucky line-diff wise, then this is two git cherry-pick's, and firing up the release script twice.
stale branches, that won't ever receive fixes or backports, can be deleted (and from then on rely on the tags to retain the release history of that now finalized branch of the version tree).
from my POV it's a pretty straightforward setup, but i'm not saying that this scenario is something that you should or desire to support, though.