No idea what else it would break but what about always using a maximal virtual desktop size on Wayland and ignoring the monitor coverage? That would be a change limited to wayland_resize_desktop, and in theory the rest should just work as if we had very very large monitors?
This idea briefly crossed my mind, but I disregarded it because I thought that `vscreen == desktop_win` was a core assumption. If that's not the case, I think this solution is worth exploring more. There are some technicalities to resolve, because we can't resize the desktop during the process init when we receive initial output info (we don't have the desktop window yet, you may recall the discussions about the issue from an earlier MR), and rely on `explorer.exe` to do this for us after creating the desktop window.
It's not a very common scenario, or is it?
Unfortunately, it's quite common. For windows larger than the vscreen, this is automatically an issue because parts of them are guaranteed to be inaccessible, but those parts may be visible from the user's (compositor) perspective.
I have also seen some apps end up in completely arbitrary (inaccessible) places for unknown reasons. That's true under winex11, too, but there they seem to eventually get moved to more reasonable positions. Perhaps the X server plays a role here, or something else is going on, and I need to investigate further in case there is something we can replicate.