Xpra
How does it connect the two Xs? It could simply connect to X1 and X2 as a normal client and forward screen data from X1 to X2. But the README refers to a protocol change. It uses a protocol with Unix domain sockets in ~/.xpra. It is designed to be reconnectable, which might require client/server separation. It does make the interaction between them clearer.
How does it handle OverrideRedirect windows? Presumably compositing has to work for these, and so X added something to catch them.
Xvfb presumably allocates storage for the screen. Can we remove or minimise this? Does it matter? If it is never used, it only consumes swap space. If it is never written, it should never get faulted in. If windows are not really mapped into the root, it should not get touched. The docs note "the screen would just be black anyway (because we don't composite properly, y'see)". Composited windows are not actually displayed: their contents are redirected.
How do keymaps work? Presumably it could just copy keyboard from host X server to sandbox X.
Docs say "As a first release, some lower priority features aren't included -- it doesn't support window icons, transient hints, shaped windows, cursor changing, input grabs, clipboard sharing, etc." Omitting these is actually a feature, from a security point of view. The simpler the better!
"The trickiest thing overall, actually, may be maintaining stacking order sync. Before processing any mouse event, stacking order must be accurate." (from xscreen.txt) This is why I abandoned the Xnest approach. Event processing within the X server looked horrible. Xpra just tries hard to keep the window positions and stacking information in sync.
WarpPointer: this is part of how xpra generates X events. It does not forward pointer movements from the hidden Xvfb to the host X server.
What happens when multiple clients connect? It looks like the old one is kicked off.
Advantages
It uses Xvfb, so the client sees whatever it supports: Render extension etc.
It works at the pixmap level and the protocol is very simple. The client would work on non-X displays. It could work with really simple window systems such as the EROS Trusted Window System.
Limitations
Performance
Don't get the benefit of hardware accelerations. Xvfb must perform graphics ops itself.
Applications that are not likely to work: video players (e.g. Totem)
Screen depth has to match between servers?
Having to sync window stacking and position worries me. I would not want to implement it, but if there is a working implementation that is maintained I would be happy to use it. The window contents problem is not so bad since we have compositing. Is using X's compositing better than the approach that the rootless X server (e.g. on Cygwin) uses?
Accessibility: I'm not sure how accessibility works on X, but I suspect that putting everything into a pixmap breaks it.
Bugs
xeyes: Background of irregular windows not filled in. Could handle by reparenting to a rectangular window on the server side.
What work needs doing for use with Plash
Better window management: No async grabbing of focus. Restricting menus.
Helpers for setting it up with pola-run. Xvfb, server and client can all be in separate sandboxes.
Trusted path clipboard and forwarder.