The wire format and the initial implementation are definitely flawed, but if you fix them you end up in the same situation again where you break everything every release and you go through all this politics trying to get everyone to use yet another new protocol and implementation. I see various complaints about that and it always comes back to the same thing. We have alternative implementations of the protocol but nobody uses them because of this. Consequently this is the same reason that it took so long to fix issues in X.

I see what you mean with that document, but if you have been watching then none of that stuff is new or unique to Wayland. What you may have missed is that this document is a reaction to the politics that already were around in the X days. (I was alluding to this earlier when I was talking about WM atoms, the popular desktops already have their own sets of policies there that are necessary and incompatible and in some ways do limit the expressive power of clients)

Not working with networked clients is a minor detail. It's trivial to have a user upload a compositor script to a different machine. If it becomes annoying to do it manually then a client that needs more features simply needs an automated way to do this. Still no need to touch the Wayland portions there either. I actually do appreciate the efforts to fix these issues with the whole shmif setup and I sympathize, but it's the same uphill political battle if you want to push that out to the rest of the ecosystem.