Rebasing for security seems odd. Usually one has to re-evaluate security completely after a rebase. In my experience, security features randomly break upstream like everything else. There is no stability guarantee.
Maybe it is odd, but backporting Intel Boot Guard or vboot to old branch and supporting it there seem to be equally odd. I also had in mind security bug fixes, which also may be not easy to back port in light of missive tree changes and lack of QA to confirm things works in the same way. Of course in security bug fixes would be way easier to backport then features.
Well, okay, I don't think that's what anyone here meant when we said "backport security fixes". I meant actual bug fixes, like there was a missed size check leading to a potential buffer overflow somewhere -- that's something that you can relatively easily backport most of the time. And for that, maintaining stable branches so not everybody has to do the tracking and backporting on their own would be great (if someone has the time to do it).
But of course you can't backport things like vboot or BootGuard support to an older branch -- those are huge features that dig deep into coreboot internals in many places. Those features are exactly the kind of things that require these tree-wide API changes that this discussion started about. So... I'm not really sure what you want here, tbh. If you want to get all these big new features on your board, then you should forward-port your out-of-tree patches to a newer release, and you'll have to deal with the problems caused by all the big API changes. If you don't want to deal with big API changes, then you should keep your stuff on a stabilization branch and only backport specific bug fixes that you need -- in that case, you'll of course not get any big new features. I understand that you might like to have both but I think that's just fundamentally impossible -- big new features just tend to require deep, invasive changes.
Do you place spatch in this category?
I mean, do you see it as too burdensome to mandate that changes affecting the tree more than some TBD threshold are to be generated by an spatch which must also be contributed?
I think we could encourage that, I don't think it's really something you can make a hard requirement. spatches just don't work well for all kinds of API changes. Starting this as a sort of "experiment" like you suggested to see how it goes sounds like a good idea.