It's a short, vague explanation that, other than a correction for a significant inaccuracy in the original version (which I think demonstrates a serious lack of research!), has had no update since it was originally published several months ago, despite the almost universal criticism of Canonical's reasoning by the community. I don't think this is particularly coherent.

It is definitely not vague and seems to be very coherent in their description of features that both X and Wayland are lacking. I'm not a Linux dev but their points seem well justified.

They have maintainability across a wide number of devices as a requirement. They have low powered devices with existing, third-party, potentially closed source graphics drivers as a requirement.

I don't know about anyone else here, but every time I set up a new system I have to waste hours getting X11 and the console resolution working right. Sometimes, they never work right. Add to that modern features like display brightness, backlit keyboards, power management, external monitor outputs, and touchscreen input with gesture support and it's unrealistic for X11 to spread to the vast number of new, lower powered devices with less technical users without some serious further work to standardize and normalize handling of differences.

Therefore I am glad, for the nontechnical majority of the world, that someone out there is bothering to try to make a reference open source mechanism for removing these problems so an install doesn't end in crashes with weird kernel boot messages about drm and BIOS upgrades and X configurations and input device drivers... even if I continue to use gentoo myself.

Hence Wayland, but Canonical, for some reason, want to be the only people not to use it.

Oh. Maybe I gave them too much credit.

    However, our evaluation of the protocol definition revealed that 
    the Wayland protocol does not meet our requirements. First

Why?

    more extensible input event handling that takes future developments 
    like 3D input devices (e.g. Leap Motion) into account

and

    we'd rather avoid having any sort of shell behavior defined in the 
    client facing protocol. 

A very technical explanation there. Full of Really Good Reasons. Very coherent, what ever that means.

They've basically just said; 'we don't want to use it'.

Fine.

...but that 'Why Not Wayland / Weston?' section, with its ludicrously obvious 'we corrected this criticism that we previously had up here, woops' is just painful to read.

They gave two ways in which Wayland didn't meet their requirements. And your objection to those reasons is...well, I'm not really sure. You just quoted them and aimed for sarcasm as though they were obviously wrong.

If you're wondering what "coherent" means, it's kind of the opposite of your post. Are you saying that their reasons are incorrect? Are you saying you don't understand them? What?

I'm saying, a couple of lame excuses* is not a good reason for going their own way.

I'm sure you could come up with 2 good reasons for going with wayland too, if you tried for more than 5 seconds. Does that means it's a good idea?

If they want to explain why they don't want to use wayland they have a couple of choices:

1) Say, 'we don't want to use it', and not give a reason.

2) Say, 'we can't use it, because of...'

I totally respect both of those positions, but the road they've taken doesn't impress me at all.

Both of the (2) reasons they give seem trivial and over coming them, would be, effort wise, surely significantly less than implementing an entire display server.

Can you see then, why their argument doesn't exactly make sense?

If you have some serious and significant concerns with a project, then list them! Don't pull out a couple of random lame* things that you don't particularly like and then say those are why you've decided to devote a huge amount of effort towards something.

*yes, lame. Are they seriously suggesting you can't use a leap with wayland? ..and that justifies, as a policy decision, a reason to go forward with mir? Absurd.

Those reasons aren't good enough reasons to split the community. They're reasons to negotiate and to help improve Wayland.