Depending upon the implementation, clients can share their window contents with Wayland via DRM buffer objects, IPC shared memory, or other types of memory buffers. The clients then send a list of the damaged areas to the display server to initiate a re-draw, in a similar manner to X's Damage extension. Wayland handles input, focus policy, and transformation of coordinates while taking in for account the composited window elements. The core Wayland interfaces currently describes surfaces, input devices, resize requests and events, buffer objects, outputs, and visuals.
Each Wayland Server implementation can provide its own distinct set of interfaces, which could potentially lead to some problems in the future, but hopefully this will not end up being much of a problem down the road. There is dependence in Wayland currently on EGL, which is provided by a modern Mesa stack. Wayland though does not have a hard restriction on using EGL / OpenGL. The same Wayland compositor can use DRM, X11, and Wayland (nesting itself). Wayland is not an X Server with regard to having a wire-transparent protocol, drawing functions, and other features of the X11 protocol, but is rather a hopeful replacement to the X Server in the future.
With Wayland, you can also run an X Server within Wayland. On the other hand, right now with the samples, you can even run Wayland within an X Server. This is likely where Wayland will likely find uses initially by Linux distribution vendors for still providing a Wayland Display Server desktop in cases where the necessary driver requirements to supporting Wayland are not met. [My estimate is to see this implementation in Ubuntu 12.10.] Via running Wayland over X may be where the first non-Linux implementations are supported with the BSD and Solaris operating systems still lagging behind in DRM (GEM/TTM) and KMS support.
Egbert Eich then given a brief demo of Wayland. More Wayland information can be found in other Phoronix Wayland articles.