Currently it's
Display <- Compositor <- X11 Client <- X11 Server <- App
Wayland:
Display <- Compositor (Wayland) <- App
Source: http://wayland.freedesktop.org/faq.html#heading_toc_j_8
See, this makes no sense to me. The truth of this statement holds if I substitute s/remote/local/.
The fact is, Wayland manages a shared resource via a well-known API. This is the very definition of client/server architecture. There's no additional technical hurdle to be crossed to support network transparency.
So memory buffer handles can still be passed around, since clients rarely touch the raw data. (Indeed, this is exactly how X11 works.)
Edit: You know what, I should be less passive-aggressive about that. I'm not confused by your diagram, it's just wrong. :-)
Display <- X server <- Compositor/WM <- X server <- Your app
Where compositor/WM and your app are X clients, i.e. there's lots of context switches between clients and the server.
I personally don't see much wrong with this design BTW, despite the context switches X is pretty smooth even on some pretty wimpy hardware (eg. Raspberry pi, or Nokia N900, or the wimpy Pentiums I ran X on 15 years ago).