@mwinter Thanks for the feedback. It's good to hear these ideas make some sense out of our echo chamber as well.
Responding to the questions:
That happens transparently when one does snap revert. The revision reverted out of is blacklisted and will not be reinstalled. When a new revision shows up inside the scheduled window, then that is installed and the problematic revision is "jumped over'.
Yes, you don't even need to take it out: just publish another revision (new or old) and that will be the new tip. Soon we'll also introduce live feedback over how well the roll out is taking place, and even block it automatically if there are strong hints that the new revision is disrupting clients.
They'll refresh into the new tip. Whatever you release into a channel becomes the current target for every client.
The scheduling logic allows selecting multiple slots, so you can put in every slot that makes sense and the system will strictly respect those over the two months time frame. If after that none of the slots managed to be respected and there are updates pending, the system will disregard the slots as they're not being exercised for some reason. There might be clock issues, for example, or perhaps the scheduling window falls overnight on a machine that is never turned on during that time.
That said, phasing out the requested window with less strict windows before going totally open is an interesting idea.