That's the whole point I've been making some posts earlier.
Suppose Haiku gets finally in beta, in the development branch people begin to update things, and break where it's necessary. In the meantime the stable branch gets mature enough to be finally called R1.
Now, after that suppose some parts of Haiku get nice updates or even rewrites. For example a new media_kit, new interface classes, a Tracker rewrite, a new Deskbar.
This won't be an R2, but certainly it isn't an R1. So we can begin to merge stuff back and announce an R1.1/beta. And the cycle restarts until we feel confident enough we can call it R2 and then announce R2/beta, R3/beta and so on.
Similarly, for the current release we can mark some commits to be just fixes and those could be merged back updating the release.
E.g. we can have a yearly R1.0.X.
R1/beta -> R1 -> R1.0.2 -> R1.0.4 -> R1.1.0/beta -> R1.1.0 -> R1.1.2 -> ... -> Ra.i.j -> ... -> R2/beta -> R2
I'd be the first to be available in merging back my code if such a model would be adopted, and I'd take myself the job of merging back in the stable branch my stuff.
And BTW, this is very similar to what the original BeOS release model was.