>> Can you explain what would you call "accelerated xrender" then?
> Something that doesn't really exist. Modern videocards don't have any intrinsic way to accelerate drawing of thick lines (especially with antialiasing), so X-server has to do it in software. Of course, thick lines and everything else can be emulated in shaders but as far as I know, no driver in X.org does this.
Many (most?) Xorg drivers use shaders. And that's not a problem of X11 protocol, not even Xorg problem, that's a problem of good drivers implementation. Drivers are the best place to implement hardware-specific optimisations. It's much better than having every software to carry all the possible hacks for all video adapters in the world. Unfortunately you don't have such option in Wayland.
> X.org can use 100% of CPU in graphics-intensive apps.
Sure. If it was multithreaded it could use 1600% CPU. But in real world it does not. So single-threaded design is better here. "Do not add new functionality unless you know of some real application that will require it."
> It is. There is exactly ONE implementation of X protocol with XRender extension.
Really? Xfree86, Xorg, Kdrive, Xwin32, there're even VNC servers supporting it.
> clients can happily render the next frame while Wayland is processing the request to render the current frame.
You can use Xorg this way too. The difference is that you CAN do that on Xorg, but you HAVE TO do that on Wayland.
> If you haven't noticed, I've just used your logic for these reasons.
I haven't. My logic is simple: Wayland adds more work to people, lacks lots of features, but fixes no X11 problems and nobody wins from Wayland.