set_sync's current definition is coherent for a strict "mailbox" content model, but we don't really have that when new protocols create queues of state, or even when we have fences that could result in a content update being presentable between the asynchronous
set_sync call and an upcoming vsync.
I'm proposing that any as of yet "unlatched" state the compositor has queued up should be pushed into the subsurface cache on the synchronous transition. This gives the benefits of stopping updates "immediately" on
set_sync, and potentially releasing unpresented buffers that the client might want to use for whatever operation it's decided requires synchronous operation.