The DRI PRIME Wayland support isn't via changes to the Wayland protocol or even to the Weston compositor, but namely come down to Mesa changes. The Mesa Wayland EGL back-end doesn't support DRM render-nodes but that is changing soon through the use of __DRIimage. These Mesa patches for the DRI_PRIME support for Wayland allow an id_path_tag to a specific GPU to be set via an environment variable or the traditional method of setting DRI_PRIME=1 for falling back to secondary GPUs.
The DRI PRIME Wayland rendering on secondary GPUs will allocate buffers without tiling to render to compared to the X.Org Server PRIME where it renders to a tiled buffer and a copy mechanism to pass the buffer to the primary GPU. The Wayland PRIME implementation is slower than if no PRIME is utilized, but a new solution is still being devised.
A more ideal and performant situation is using an embedded Wayland compositor on the secondary GPU and then run the game/application inside there, which in turn is shared with the main compositor. Axel Davy, the developer that published these DRI_PRIME Wayland patches today, is planning to write a Weston shell designed for embedded full-screen games to make Weston resize to the game and close the embedded compositor when the game closes.
This embedded compositor implementation designed for gaming would be more flexible and avoid a buffer copy for full-screen games, but the user would have to use a script for launching the game. Over DRI2 PRIME with an X.Org Server, v-sync will always be supported and the PRIME design is much simpler.
These Mesa DRI PRIME Wayland back-end patches can be found on the Mesa-dev mailing list. This work is going to be out of the question for Mesa 10.0 due to the imminent branching but it should be on the table for the next Mesa release in three months.