The beam-racing compositor is a cool idea. It seems to me, however, that it could create visible jitter for applications that use traditional vsync-driven frame timing --- e.g. an animation of vertical motion would see a one-frame latency change when the damage rectangle crosses some vertical threshold.
If you're animating (or doing smooth window resizing), then your "present" request includes a target frame sequence number. The way I analyze the text editor case is that it's something of a special case of triple-buffering, but instead of spamming frames as fast as possible at the swapchain, you do multiple revisions for a single target sequence number. The last revision to make it ahead of the beam wins. If you have a smooth clock animation in addition to some latency-critical input sensitive elements, then the clock hands would be in the same position for each revision, only the other elements would change.
If done carefully, this would give you smoother animations at considerably lower power consumption than traditional triple buffering. It's not the way present APIs are designed today, though, one of my many sadnesses.
As I hinted, this is a good way to synchronize window resize as well. The window manager tells the application, "as of frame number 98765, your new size is 2345x1234." It also sends the window frame and shadows etc with the same frame number. These are treated as a transaction; both have to arrive before the deadline for the transaction to go through. This is not rocket science, but requires careful attention to detail.
