Sorry for being a bit late here, but I wanted to second what Nico said. It's important to not add undue burden to the development process. I think the master branch is meant for development, not for shipping long-term stable products. If you're installing coreboot in a train or medical device, then why on Earth would you want to rebase that onto the latest master after you have stabilized? Cut yourself a private branch and cherry-pick fixes back to that as necessary. As an open source project, coreboot doesn't have anywhere near the resources to do enough QA to guarantee that the tip of the master branch (or any branch or tag, for that matter) was stable enough to be shipped in a product at any point in time... even Linux cannot do that, and they have way more resources than we do. It's always best effort, and if you want to put this on something you want to sell for money, you'll have to pick a point where you take control of it (i.e. cut a branch) and then do your own QA on that.
For the argument of supporting out-of-tree development, honestly, I think coreboot is a GPL project and out-of-tree development is opposed to the spirit of the GPL, if not the letter. The whole point of being open source and copyleft is that we can all work together on one tree and integrate with each others' changes in real time. If someone wants to develop their own patches in a secret cave for a year and then dump them all on the coreboot Gerrit all at once, and they can square that away legally somehow, fine... we can't stop them. But I think the extra friction caused by that is on them and we shouldn't make work for mainline developers harder to support that case.
For the case mentioned with ACPI compatibility, I think it's a bit different -- since coreboot versions can't be tied directly to OS versions, there's value in trying to maintain some back and forwards compatibility for the interfaces crossing that boundary, and I think we generally try to do that where we can. We can try to codify that if people want to. But I think it should be something that encourages maintaining compatibility while still allowing for flexibility where necessary... i.e. the guidelines should be written mostly with "should" and not "must".
I'm okay with maintaining a "running log of major changes" as long as it doesn't create too much of a hassle to maintain. coccinelle spatches can be encouraged where it's useful but I think they should always be optional... some migrations can be easily represented like that but others not so much. And if I'm flipping the arguments in a function that's only used 2 or 3 times in the whole tree, it's kind of overkill to write an spatch.