[cycloptic]

If you're talking about making something that is Linux only, that also would be a no-go for X clients that expect to run on other operating systems. They would still want to maintain the old code path, so it wouldn't help much.

You do have to bring your own multiplexing in the X world if you were implementing an X compositor. Maybe that's unfortunate to you that the focus changed to X compositors, but Wayland didn't change the fact that this work has to be done by some willing party to get that to work.

I wouldn't call myself a "Wayland fan" but what you are saying isn't really a problem, the different window managers can choose to implement it just one way. They don't have to do it N different ways, of course they will do it differently if they have a valid reason to. From an application developer perspective you shouldn't have to deal with this problem, I'm sorry if you are a toolkit developer and this has caused you pain, but in my experience nearly all of the bits that you would need to have to do a native port to Wayland aren't specific to any window manager.

[jude-]

> the different window managers can choose to implement it just one way. They don't have to do it N different ways,

Not holding my breath. Just because you have a standard doesn't mean all implementations behave the same. In fact, they usually don't, which is the problem.

> but what you are saying isn't really a problem

Thank you for proving my point about being in a position where you don't have to suffer the consequences of your bad architectural decisions.