> Still, it does not seem a really fundamental problem, it must surely be solvable from within X?
X gives you two options: set DPI per displays. The thing is, you cannot drag windows between displays, the app has destroy it, connect to another one and recreate it here. There's even no mechanism to detect multiple displays other that user setting up the DISPLAY env variable.
Or you can do, as the Xorg does: use multiple screens on a single display. Here, the limitation is, that all screens have to have same DPI.
Neither of those are acceptable for modern display server.
> it will break screen capture tools,
It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them. Just like it is unacceptable to integrate user address book to your app by going through its internal files, it is unacceptable to screen grab by snooping windows of other apps. In both scenarios, your app must go through API, which puts the user in the control, whether the app is allowed to do that. Wayland enforces such protocol for screen grabbing and input handling; those app who do not bother... well, the train will leave the station without them.
> other things that are dear to us like xwit, xdotool and the like
Same as previous, but for input handling.
> Just for that silly mixed-resolution screen problem?
No, there are multiple problems. For another, surely you would like screen lock that doesn't flash your desktop on unlock?
> I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.
See even here on HN, it is important for many. Just few days ago there was a discussion under article about i3 and how to drag it into hidpi world in 2021. On the other hand, the mainstream user doesn't even know why they would use xwit, even if they knew it exists.