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).
I should note that using shared memory that way is not allowed in Wine. It's not considered acceptable that one crashing app can take down the entire session. Shared state has to be stored in the Wine server.