Devils are in the details

No. It may require different knowledge, but the skills are exactly the same.

So is having a good experience with a desktop that is designed to both use XRender and OpenGL to do the same thing. :P

> 1) some HW don't have open specifications!

Yes. This sucks. But there is plenty that do, or at least are 'open enough' that they work out well. Nowadays we have enough hardware on the market made by Linux-friendly-enough companies that I think it's pretty reasonable to expect that if people want to run Linux with the "Full Desktop" experience that they can obtain the necessary hardware.

And like I mentioned before: On modern hardware there is no longer 2D. It's not simple like that anymore. Drivers capable of driving XRender are going to be capable of doing other stuff. It's a API that is designed for hardware that doesn't exist anymore, I suspect. I am sure that other people understand the details better.

What we really need is a DE environment that is willing to depend on fully functioning subset of a particular popular API. OpenGL is probably just fine in this regard. It should concentrate on just working with that set of assumptions. Not trying to support multiple APIs and forcing users to choose when they have neither the knowledge of the hardware or understanding of the environment necessary to make a proper choice.

Then we need a 'lite' fall back were there is no acceleration available at all. That all your expected to be using is just pure software rendering or bit blotted display or something like that. Even if it ends up slow because application developers learn to depend on a properly configured computer it is not terribly important. It just needs to work.

> 2) Application developers may not own the problematic HW

This is what quality assurance and test suites are there to deal with.

Live CDs, usb drive images, automated benchmarks. It's easy nowadays to setup previews and things that people can just download and run. No compiling necessary or deep understanding. Trace logs and scripts to help providing debug information to developers should be built into the evaluation environments and nice documentation on what developers want needs to be provided. Information on the experience of the tester can be uploaded automatically or be sent with a press of a button.

It's often very useful to have the folks that QA be completely different from the folks that develop. Programmers are often 'too close' to the software to be able to see how users will approach it and what issues they will find. This helps issues get identified quicker in many cases.