From what I understand of the summary, the GetCurrentDisplaySettings implementation can be inconsistent and relies on figuring out everything the compositor supports by guessing.
Perhaps I am misunderstanding your concern, but the current implementation of `GetCurrentDisplaySettings` (which uses the shared memory region) does provides consistent and real output information across all Wine processes, there is no guesswork involved.
Since the Wayland output state of different clients/processes can be (transiently) out of sync, we effectively treat the Wayland output state of the desktop window process as the authoritative one, and all other processes use that state (through that shared memory region) when reporting back information, in order to be consistent both among them **and** with the Wine monitor information.
There are some other benefits to the shared memory approach, which will become important in the future. For example, the ability to consistently apply/simulate application initiated mode changes (i.e., `ChangeDisplaySettings`) across all processes (since Wayland doesn't allow normal clients to actually change the compositor mode).
Have you bugged the Wayland devs about adding some protocols to support viewing the display specifications?
This might go against their design choices, but it's not much of a danger since applications can't self position or control other windows, it would just be asking the compositor what displays are available and what modes they support.
All the information is already provided through the wl_output (and xdg_output) events, it's just that each client is responsible for tracking these events and maintaining the total output state on its own. That's absolutely fine for the overwhelming majority of clients, so I don't expect upstream to be interested at all in providing another way to get the full output state (plus there is a roundabout way to achieve this, by creating a new wl_registry and synchronously waiting for initial wl_output events). In the end I don't think that it would be enough on its own anyway, because although it would help with some aspects of the problem, there would still be cases where the Wayland output state of some process and the the Wine monitor information could become desynchronized.
Maybe on top of that you could allow choosing a display to output to (rather than exact positioning, it's just a general "I want to be on this display") which would work well for games, as they tend to have display settings there to see what they can do.
This is already supported by the xdg-shell protocol for fullscreen surfaces, which is the main use case for gaming needs, and the Wayland driver will make use of this feature (the full series already uses that).
I hope all the above help clarify the design decisions a bit more.