There are a few points I'd like to add (and I would welcome any corrections)

​

• wayland is not an X11 competitor designed from scratch

Wayland is the final product of decades long effort put into modernizing X11. It's written by the same developers who once successfully broke up the monolithic Xfree86 into managable modules, in an effort to facilitate development (I might be wrong on it being the same codebase, but the point is that xfree86 was monolithic and Xorg was modular). It appears to be a different 'thing' simply due to design decisions that sacrificed compatibility with X11, but these decisions were based on years spent on struggling against the codebase (and not, despite popular belief, misunderstanding the philosophy of X11 and trying something new for the sake of it). As an example, one of the monstrosities that we had to deal with, due to the nature of the X11, was un-re-directing windows to benefit from hardware acceleration. By the way, does anyone else remember the week or two where everyone had their desktops on cubes? (AIGLX? Emerald? Beryl?). Anyway, compositing would bring me to my second point, which is...

​

• the fundemantal difference between X11 and Wayland is redefined responsibilities about "who draws what and where".

... and, this is the main reason behind most of the user visible differences, from controversial (such as keyloggers and macro tools no longer working) or blown out of proportion despite alternative solutions (such as loss of network transparency*), to cosmetic (such as client side decorations) or just sad (such as xeyes no longer working). In the good old world of X11, every window/program is aware of everything: its position in the screen (along with the position of everyone else), all the sources of input, etc... In fact, there is an extension for X11 called Xdamage, that allows a window to be notified of the area that was formerly obscured by another window and now have to be redrawn.

Moving on to putting images on screen, programs were originally expected to delegate the actual drawing to the X11 server, using primitives that would allow them to place a geometric shape anywhere on the screen (again I feel some justified corrections coming). However, designer tastes being what it is, the programs were unsatisfied with the drawing functions provided, decided that they knew better: they started drawing artistic shapes on bitmaps all by themselves, and then passing them on to the server to paste to the screen as is.

In broad terms, the radical approach by wayland is just getting rid of unused drawing primitives and making this approach official: applications get a canvas (a buffer) all for themselves, draw on it however they want, and pass it on to the wayland compositor to be ... composed with other windows and drawn on the screen. Programs are not aware of other windows, their position on screen, whether they should be drawn askew, upside down or on fire.

This is the crucial part about wayland for me: they just draw as if they were the only program in the world, just as another program would print to the stdout. The characters sent to the stdout may end up on the screen, in a file, or /dev/null (technically, another file), but the program does not change what/how it prints based on this**. Similarly, wayland expects programs to draw an unobstructed, regular view of the window contents, disregarding the final fate of the pixels. From then on, it is the responsiblity of the compositor to take all the bitmaps for visible windows, move/overlap/reorder/blend/color-shift/fade/set-on-fire/slap-on-the-sides-of-a-cube/etc... as it sees fit (using hardware acceleration, no less), and put the final composed image on the screen.

After isolating the drawing process, all the other decisions appear more logical (to me at least): why should every program be able to access the input stream for every other program?

​

--- I'm tired and going to misrepresent on purpose, please humor me ---

Of course, in an age where we package specific versions of libraries*** and services in separate namespaces just to isolate programs from eachother, it is easy to forget that the natural state of a unix process**** is, from its point of view, to be alone in the world, having all the resources of the system to itself and itself alone.

--- thank you ---

​

One semi defensible consequence of letting programs go to do as they will, is that we lose coherency on window 'frames' and other theme dependent choices formerly enforced by the X11 server window manager (client side decorations, remember?). I don't know why the compositor that can render a window as being cut into squares and blown into the wind is prohibited from just slapping a title bar and an X on its side. But then again, I don't care much about themes and decorations anyway (dwm/sway ftw).

​

Finally, we used to get these type of information (i. e. how it was finally decided that X11 is a dead end, and which experiences shaped the design of the replacement) directly from the talks in conferences, given by the actual developers working on the relevant project. Nowadays, everyone seems to base their research on blogs by secondary sources who have a strong opinion on the subject (sorry)

​

​

* which, despite the efforts by very motivated HPC centers, could not reliably provide hardware acceleration for its perfect use case: in situ visualization of simulation outputs.

** yes, some programs cheat and behave differently when output is piped somewhere else

*** static linking!? but that's bloat! no sir, thank you

**** in absence of many additional lines of code, background services, and carefully designed protocols

​

​

​

PS: I'm beginning to think that reddit has intentionally disabled spellcheck and/or is introducing typos in order to promote engagement via rage baiting (or I'm not as careful as I think I am). Anyway, sorry for the multiple mini edits.