> Wayland has another fundamental problem: to keep the protocol small it tends to implement everything in a single compositor application. No separate window managers, no custom dockbars, no tools to manage multiple monitors (xrandr), and obviously no small useful tools like x2x/xdotool/xautomation. Regular applications are only allowed to draw something or listen for input. Need something else — write/patch the compositor.
That's not different than today, the X window managers have to know all about multiple monitors, dockbars, etc. and a compositor has to receive all the window contents, compose them together then provide a full screen bitmap for final display which is also not substantially changing. I don't know where you get the idea that there won't be window managers in Wayland, window managers (plural) are the future of Wayland, they are just able to talk more directly with the graphics hardware for final output, since they are doing all of the work today anyway.
I have no idea what 'wayland' protocol you are talking about since it seems to have no relation to the actual Wayland project. You might be interested in watching some of the Wayland presentations at LCA to learn more info.