If -- and that's a big "if" -- Wayland's model is determined to truly be the successor to X, then it's really just a matter of adding a new backend to a toolkit that already has half a dozen.
See, though, the entire reason Wayland works the way it does is because real applications don't need additional features in EITHER backend. The future that we're approaching is one in which all rendering is done via OpenGL (usually through a higher-level toolkit/library interface), in which X subwindows are unused, in which DBUS facilitates all high-level desktop app communication, and in which all X really does is provide the basic window stacking/management features on top of the in-kernel or library-ified graphics and input components. That's why Wayland is so simple. Nobody really needs the features the Wayland design lacks. All modern applications need from the windowing system are windows, direct rendering, compositing, input, and a few other basics.If GTK was to get popular on Wayland then that means that unless new features are supported both in X and in Wayland then that means that GTK won't be able to benefit easily from improvements in either one.
Almost all interesting features -- including allowing apps to move between X servers like you just asked for, as well as networking -- are really toolkit problems and library problems. A modern toolkit's abstraction layer needs very little outside of a way of getting hold of an OpenGL context, getting input events, and low-level stuff like threading and I/O and basic audio. Current toolkits have bigger abstraction layers mostly just because they were designed in the day and age when the X drawing API or Windows' GDI API were actually considered useful.