X's network transparency has wound up mostly being a failure
I was recently reading Mark Dominus's entry about some X keyboard problems, in which he said in passing (quoting himself):
I have been wondering for years if X's vaunted network transparency was as big a failure as it seemed: an interesting idea, worth trying out, but one that eventually turned out to be more trouble than it was worth. [...]
My first reaction was to bristle, because I use X's network transparency
all of the time at work. I have several
programs to make it work very smoothly,
and some core portions of my environment would be basically impossible
without it. But there's a big qualification on my use of X's network
transparency, namely that it's essentially all for text. When I
occasionally go outside of this all-text environment of
emacs and so on, it doesn't go as well.
X's network transparency was not designed as 'it will run
well'; originally it was to be something that should let you run
almost everything remotely, providing a full environment. Even apart
from the practical issues covered in Daniel Stone's slide
clear that it's been years since X could deliver a real first class
environment over the network. You cannot operate with X over the
network in the same way that you do locally. Trying to do so is
painful and involves many things that either don't work at all or
perform so badly that you don't want to use them.
In my view, there are two things that did in general X network transparency. The first is that networks turned out to not be fast enough even for ordinary things that people wanted to do, at least not the way that X used them. The obvious case is web browsers; once the web moved to lots of images and worse, video, that was pretty much it, especially with 24-bit colour.
(It's obviously not impossible to deliver video across the network with good performance, since YouTube and everyone else does it. But their video is highly encoded in specialized formats, not handled by any sort of general 'send successive images to the display' system.)
The second is that the communication facilities that X provided were too narrow and limited. This forced people to go outside of them in order to do all sorts of things, starting with audio and moving on to things like DBus and other ways of coordinating environments, handling sophisticated configuration systems, modern fonts, and so on. When people designed these additional communication protocols, the result generally wasn't something that could be used over the network (especially not without a bunch of setup work that you had to do in addition to remote X). Basic X clients that use X properties for everything may be genuinely network transparent, but there are very few of those left these days.
xterm is any more, at least if you use XFT fonts. XFT
fonts are rendered in the client, and so different hosts may have
different renderings of the same thing, cf.)
What remains of X's network transparency is still useful to some of us, but it's only a shadow of what the original design aimed for. I don't think it was a mistake for X to specifically design it in (to the extent that they did, which is less than you might think), and it did help X out pragmatically in the days of X terminals, but that's mostly it.
(I continue to think that remote display protocols are useful in general, but I'm in an usual situation. Most people only ever interact with remote machines with either text mode SSH or a browser talking to a web server on the remote machine.)
PS: The X protocol issues with synchronous requests that Daniel Stone talks about don't help the situation, but I think that even with those edges sanded off X's network transparency wouldn't be a success. Arguably X's protocol model committed a lesser version of part of the NeWS mistake.