The issues and solutions below have come from a discussion of how to make changes to the CSS2 REC, but could be applied to any REC maintenance.
For reference, here's the process diagram for modifying a REC: https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#rec-modify
The path to consider is the one where there are substantive changes but no new features. According to the diagram, we should be able to skip the WD phase. But skipping the WD phase means we can't get the changes published on TR until they are ready for inclusion in a CR draft. Review needs to happen before a change is ready for CR.
One option is to always take the REC back to WD, even for changes that should allow us to skip that step. This gets the changes published on TR and gives us the WD stage to review and vet the changes with tests. This full process cycle should not be necessary, and it's a little strange to have a REC stuck in WD just to get substantive errata done.
Another option is to keep the changes in an ED until they're ready for CR. This fails the goal of having changes reviewed on TR.
Both of the options above also have some churn when we have some changes but not all ready to graduate to CR - we have to prepare a draft with only those changes ready for CR, move them through the process, then reintroduce the rest of the changes to a new ED/WD
Another option, and I think more usual, is to issue a Proposed Edited Rec (this is the same as publishing directly as a CR, skipping all earlier stages) - https://www.w3.org/2015/Process-20150901/#revised-rec - the CR can be republished if and as needed without going back to WD. This does not affect the Recommendation status of the original until the new version is published as a final REC - Liam - (Alan's response: this is the method we want to use in the proposal below for those changes we know are ready for a quick CR. When we're not sure which changes will survive review and/or be adopted and testable, the problem is that the REC gets stuck in a republished CR cycle. I don't think it's good to take a REC back to CR for changes that haven't yet been vetted)
So the WG has proposed a new mechanism for making reviewable changes available on TR. We will produce a copy of the REC (CSS2 in this case) as a NOTE (CSS2-testing). This NOTE will be kept up-to-date with all proposed substantive changes to the REC, and people will be directed to review these changes in the NOTE. Periodically we will check the state of the changes in the NOTE, and those changes that have passed review and have passing tests will be folded in to the REC. This allows us to produce a CR of the Edited Recommendation that is ready to pass through the PR and REC stages as quickly as possible.