And fixing that is probably not going to ever happen until X/Mesa is dead under its own weight.
X is a protocol, and a pretty good one at that. There is no reason for it to "die", since nobody has come up with anything better yet. Both the Windows and the OS X graphics architectures are inferior.
The X server software and Mesa should get updated. But it actually works pretty well. Most of the things you list are fairly specific add-ons, and having those access the hardware separately seems like a good thing; why would I want to have all that extra crap in a single project?
People need to do some refactoring, cleanup, and documentation. But, hey, what else is new. But there is nothing really wrong with having those different pieces of functionality factored into seperate projects.
X11 the protocol was very good 20 years ago, but by now shows its age. A new X12 could use some cleanups such as removing colors, palettes and visuals (truecolor is the only relevant one nowadays), adding explicit gamma support, removing every drawing primitive except unaliased points, horizontal/vertical lines and image handling, adding alpha support, adding efficient image transfer mechanisms by mapping video-card accessible buffers in the application (XShmPutImage and glTexSubImage2D are sad jokes, performance-wise), adding blending/compositing support, etc. And that's just graphics, don't get me started about multi-screne handler, internationalization, window management or inter-process communications.
As for the "specific add-ons", I was talking about 2D X rendering, you know, the thing that draws your windows, 3D rendering, which you may have heard about, and video decoding, the thing linux users do in software because less that one "standard" per video card vendor would be unacceptable. Vaapi happens to be intel's (vdpau is nvidia's, xvba is amd's). Nothing obscure there. And if you think they're independant you either haven't looked at the problem and the hardware or your blood level is too high in your coffee stream.
At first sight, the opengl 3 level intel cards have three beautifully separated subsystems, 2D blitter, 3D renderer, media decoder. Then you find out that only one can be used at a given time, and you have to explicitely switch between them. And, in addition, things like glClear are better handled with the 2D blitter, compositing, frame filtering and deinterlacing with the 3D hardware, etc. And in practice you want to unify pixmaps, textures and movie frame buffers, otherwise pain ensues when you want to use the damn things. So the interdependance level is actually high. As a result it is *very* wrong to have these pieces in separate projects, because communication layers and version issues multiply exponentially.
Finally, I don't know about OS X, but the Windows architecture for video drivers is actually superior than the current linux ones. You have one kernel-level driver and one userspace driver, and that's it. The API is not the best possible by far, with way too many functions, communication paths and a somewhat obsolete shader microcode. But the unification of all the hardware functions in two drivers with the kernel boundary in between is the best you can have.
And, the point you missed, is that the refactoring *will* *not* *happen* for political and social reasons. Even before patches, the first step would be to unify all that stuff under one tree, and the pushback against that is demented.
OG.