Users rightfully do not care about what init system they use, as long as it works.
But making it work requires time and effort from some people. And we don't live in a world of infinite resources.

By announcing they're switching Ubuntu from Upstart to systemd, Ubuntu aligned themselves with the majority of the developer comunity and Ubuntu reduced the ammount of effort they and others developers have to put in to make it work efficiently as you said.
Ubuntu will not have to write and debug Upstart configuration files for services, they can just the share the same systemd files as Debian.
GUbuntu and KUbuntu developers will have less trouble to make Gnome Shell and KWin, which are moving towards somewhat depending on systemd, work on a Ubuntu derived distribution.

And that means they can actually spend time fixing other stuff.

jackd is not a jack of all trades.
It's a specialized application, with a very specific purpose, that it does very well.
Making a general purpose sound server requires a different set of compromises.

"Fixing" those things in jackd means, at best, extra code to support features that are not primary goals for jackd. At worse, it means sacrificing some of jackd's critical features, such as low latency at the expense of everything else.

It Lennart tried to fix jackd, then the proverbial wrench would be thrown at his head by the jackd developers.

No, jackd and pulseaudio try to solve different sets of problems.
They don't compete even the slightest. If you think otherwise, you're completely off base.

jackd is not a generic sound server, doesn't want to be and hates anyone who thinks it should be one.
jackd is a virtual patch panel for audio. It let's you take audio sources (input hardware or applications) and connect then to audio sinks (output hardware or other applications). And it does so while striving for absolute minimum latency.

But it's ill suited for general purpose.
jackd needs to be configured manually, with some detail. Eg, since jackd does not sample rate conversion, you need to select a rate.
jackd does not support hot plugging of hardware, you need to restart it.
jackd of course, will not automagically redirect your audio when you plug in your USB headset.
jackd does not provide per-application volume control.
jackd has no bluetooth support and, AFAIK, it doesn't really like the alsa bluetooth plugin.
jackd is CPU intensive.
jackd is sensitive to misbehaved applications. ...

You're 90% right, but the devil is in the details.
The X protocol allows applications to send drawing commands like "draw a line here, circle there, text with this font over there". You can also store pixmaps to the server and then reference them.
But these drawing commands can't draw anti-aliased shaped, so in the late 1990s X applications were either pushing lots of pixmaps or pushing so many tiny drawing commands it was worse than pushing pixmaps.

Then came XRender. XRender is based on pixmaps/gylphs, but also provides masking/blending operations on them.
This allows for better re-use of server stored pixmaps, which allowed for anti-aliased applications with less network traffic.
All in all, it's pretty slick.

But history is repeating itself and application developers are again going back to pushing lots of pixmaps. Qt developers concluded that, for local clients, their client-side renderer was *much* faster than the XRender based one and at some point made it the default for Qt4. For Qt5, they didn't bother with a XRender based one.

To top it off, whether it's XRender or brute force pixmap, modern X applications send so many commands they need a lot of bandwidth.Also, most X applications were never written to tolerate high latency connections, even though the protocol is asynchronous.
So, remote X tends to work poorly over the Internet, leading a lot of us to use tools like VNC, NX or Xpra.

The Xpra server runs as specialized X server and X compositor in the remote system, where the X application is to be run. Then it takes the contents of the X application's windown, scans for changed parts, compresses and sends it over to the Xpra client, which then draws the application window in the local system.
Since the X application is talking to a local X server, there's no latency there. And the diffiing/compressing ends up requiring less bandwidth than sending the raw X commands.

So, history has shown twice supporting drawing commands is a fool's errand, Wayland only supports pushing pixmaps. And only through shared memory, a Wayland compositor and a Wayland application must always to be on the same machine.

But there isn't anything stopping anyone from implementing a Wayland compositor that does what the Xpra server does. So, that's pretty much plan "A" for running Wayland applications remotely.

Yes, it's possible. All you need is to implement a compositor which is actually a Xpra-like server.

And yes, it's been worked on. Support to have Weston (Wayland reference compositor) work as a RDP server has been merged.
Not sure if it supports rootless (applications only, no desktop) already or it's rooted (full desktop). But RDP does allow for rootless.

You asked links for a shipping system.
That link has a "BUY" button.

http://jolla.com/

It's been shipping since the December 2013, using Wayland and Qt5. No X compatibility layer on this device.

No, you are misleading.

If you take a look at Wayland source code, you'll see stuff like Copyright © 1988-2004 Keith Packard and Bart Massey. quite often.
https://gitorious.org/wayland/wayland/source/0b29a2fec7801d2530bd004ae68eb9242417bafd:wayland/wayland-hash.c#L2-3

As for pushing back work to the toolkit developers, the Qt developers made the software (client side) backend the default back in Qt 4.4, because it was so much faster than the XRender based one for local clients.
And for Qt5, they simply didn't bother to implement a XRender based one.

Yes I could. Or that we're just a dream of some creature.

But that doesn't mean science is pointless.
The point in science is to have repeatable experimental results and produce reliable knowledge to advance our understanding and life.

If a christian-like God exists, then he his apparently content in letting us use the scientific process to find how the Universe he built works.
He clearly doesn't screw around with the laws of physics on a daily basis. Scientists worth the title who also happen to believe in a God are as skeptical of physics defying events as any one.

But again, we have no scientific proof that he exists or not. The christian concept of God, of a sentient all power being, makes it impossible to have such proof.

I'm an atheist.
However, your argument is wrong.

If there's a God, like the christian one, he is conscious and all powerful. He can do whatever he wants, including making the Universe work as if he did not exist. He can subvert any experiment you can can come up to test his existence.
The end conclusion is that it is scientifically impossible to prove that God exists or doesn't exist.
Stating that God probably does not exist is not science.

Don't take this the wrong way, but I think people who, like you, try to use this kind of pseudo scientific argument to state that God does not exist are just giving science a bad name.

It has been implemented for Windows server, AFAIK.
But saying rootless RDP is network transparent is a hell of an abuse of the term "network transparent".
Which of course is the root of all this drama. People confuse rootless remote applications with network transparency and they jump in anger when they hear Wayland isn't network transparent.

No, this is Slashdot, you can't have a serious discussion.
It's full of idiots who don't like shiny new things, idiots who adore shiny new things and both types of idiots love to shout at each other.

Ok. Seriously.
Wayland is a new architecture for the Linux graphics stack.
It merges the role of the display server and the window manager/compositor into one piece, called the Wayland compositor.
It is envisioned that writing a Wayland compositor is not more complicated than writing a X window manager/compositor.
Buttet point: We will not have A Wayland compositor, but serveral of them to choose from: Weston, Enlightenment, Mutter/Gnome Shell, KWin.
This is made possible because a) Linux now has a proper graphic driver stack and b) the Wayland protocol is much simpler.

The new model and the simplified protocol will allow
A) better control of the input (keyboard, mice). Currently, the X window manager/compositor do not have absolute control about the input. Besides posing some security risks, it makes it hard to implement some behaviors sanely. Things as simple as being able to mute the sound when you have a full screen application running are hard to do.
Wayland compositors, of course, get all the input and then they forward them to applications as they see fit.

B) better performance (except OpenGL full screen applications which already mostly bypass X). This will come from a number of place.
- Reduced number of rountrips (W app/W compositor/kernel instead of X app/X server/X compositor/X compositor/kernel).
- Better implementation (the X.org server isn't the fastest cookie in the world, but the protocol is so complex it's hard to do better)
- On embedded platforms (phones, tablets, Raspberri Pi) the compositor can be written to exploit hardware compositing capabilites (there's no good way to expose it though the X server).

Additionally, the Wayland protocol fixes several issues, some of which could be fixed with more extensions, some need breaking.
- Artifacts/tearing. X doesn't specify when the data sent by applications is drawn on the screen, so sometimes you get artifacts as the server or compositor draw the contents of a window in the middle of an application drawing. Wayland fixes this by making every frame perfect.
- Saner input model. The currently used X input extensions are too complicated (by the authors own admission), as they need to maintain backward compatibility with the X Core input model.
- Saner dynamic reconfiguration (resolution, orientation). Again, by authors admission, XRandR is too complicated.
- Binding versioning. Currently, if you have an application built upon components who support different versions of an extension (ie, input), it's a russian roulette on how it will pan out.

Bullet point: despite all the drama going on on Slashdot and other sites, the simple truth is that the majority, if not all, of the developers who actually put in time and effort to maintain and upgrade the X.org server, the X window managers we use, the application toolkits, etc seem convinced Wayland is the way forward and are putting in the time and effort needed to make it happen.

Wayland is not network transparent. And despite the drama, that's OK. Nobody cares about network transparency.
People (including me) do care about having rootless remote applications. We care to have something that works at least as well as "ssh -X".
For the short/medium term, Wayland desktops will run a X compatibility server (XWayland) and most Wayland capable applications will have a X fallback mode. So "ssh -X" will just keep working.
For a longer term solution, when we get Wayland only applications, we'll need to implement something like NX or Xpra for Wayland. Which is OK too, because for many of us, it's better than running X over the network.
Despite the capabilities of the X protocol, most X applications are in fact too bandwidth intensive and latency sensitive to run remotely outside LANs. And their developers can't be arsed to do it otherwise. That's why we use things like NX and Xpra in the first place.

I can't even remember what trying to use X under Windows was like. $DEITY bless memory loss.

For Mac OS X, you have XQuartz. It consists of a modified X.org server and a custom window manager and from what my Mac OS X wielding colleagues say, it works pretty well. I don't think it suffers of any of the issues you mention.

XWayland is expected to work seamlessly as well.

XWayland is a modified version of the X.org server, which instead of rendering though the kernel/hardware, renders as a Wayland client.
It makes no sense to try and maintain XWayland as a separate fork of the X.org server.

Correct, between two flushes any number of writes may have been executed or not.

Software deals with this by using proper data structures and write / flush sequences.
The most common is write ahead logging, also known as journaling, which is used by pretty much every modern file system and database.

In this approach, any changes to the data structure are first written to the WAL. Only after they've been safely committed to the WAL, the software will issue the writes to the main data structure.
Performance wise there are slight variations but the basic sequence is:
1. Write the log segment describing changes, which may need any number of HDD blocks to be written.
2. Flush cache.
3. Write the commit block. This is a write to a single HDD block, and it usually contains a checksum of the rest of the log segment.
4. Flush the cache.
5. Write changes to the main data structure.

In case of power loss or another crash, upon restart, the software will re-apply the changes described in the WAL.
A log segment which as a missing or invalid commit block is ignored.

Writes to a block are (expected to be) atomic. The HDDs have enough momentum and energy storage to, in case of power loss, finish writing that last block (HDD blocks are 4 kB plus a bit more) and park the heads (failure to park the heads would thrash your HDD in case of power loss, by the way).
Additionally, blocks have error detection/correction code. A partially written block will yield a read error.