Wayland explanations are STILL confusing and worrying users

Trying to deal with remote display at the hardware interface level where Wayland operates is probably not helpful, you could make a simple compositor which outputs to VNC but I'm sure we could do much better.

As is pointed out before, modern toolkits often use different rendering methods depending on whether they have local X (with shared memory, DRI) or remote X (serialized, sensitive to round trips), as well as for other platforms (Win32, OSX Quartz). Wayland support is provided by both a standardized protocol and a shared library which toolkits can use which is the canonical implementation of the protocol. The same approach should be taken for remote rendering, providing a standard protocol (maybe based on VNC or SPICE or including both wire formats) and a standard library implementing the protocol which toolkits can use. Then we could have real discussion on the best methods to implement a remote display protocol and what primitives should be made available for toolkit authors.

For example your toolkit, which I remind you can output on multiple type of platforms, knows which regions are scrollable, which are bitmaps, which are clickable, etc. so you can have an optimized, toolkit independent, way of remoting each region. Maybe you can pass compressed bitmaps directly and have them uncompressed on the remote end or cache text glyphs or pre-render scrollable areas. At the very least you can have some primitives that any toolkit can use to find their own clever ways to optimize for remove display.

I guess we need a team as passionate about remote display as the Wayland/X team is about local display. If the work is good enough it might even turn into a cross platform industry standard.