I don't think this MR is going in the right direction.
(struct gdi_adapter).id is internal to each driver. So it doesn't have any use in win32u. It got exposed to win32u because of the win32u/user32 refactoring.
What you need to worry about is the map from GDI adapter name \.\DISPLAY* to wl_output. The map must be stable so that each \.\DISPLAY* should refer to the same wl_output or wl_output collection (concerning mirroring) when no output changes are detected. Better, keep this map consistent even after output changes so that each \.\DISPLAY* still points to the same wl_output.
The number index in \.\DISPLAY* is from (struct adapter).id, generated sequentially in update_display_cache_from_registry(). So what you need to do is to make sure that winewayland.drv knows how to map \.\DISPLAY* to each wl_output. What winex11.drv RandR 1.4 backend does is that it always adds the GDI adapter in the same order, so xrandr14_get_id() knows which RandR output a DISPLAY index points to.
So I guess you can always add GDI adapters with them sorted alphabetically by the wl_output name and keep this GDI display index to the wl_output map in winewayland.drv. For example, entry [0] "\.\DISPLAY1" -> "DP-1" and entry [1] "\.\DISPLAY2" -> "HDMI-1". And then you call (struct gdi_device_manager).add_adapter to add "DP-1" wl_output first so when "\.\DISPLAY1" is passed to winewayland.drv, you can know "\.\DISPLAY1" points to the first entry, which is "DP-1". I don't think \.\DISPLAY* indices are guaranteed to be the same across display changes so you can ignore output changes affecting GDI display indices for now because you can remap them due to a new display device initialization, which is what Wine does now. Then, of course, you'll need to update display devices when the reported wl_output array changes by responding to their events. You'll also need to make sure the map is the same when it's called from another process.
Finally, back to the original question of (struct gdi_adapter).id, you can pass the wl_output name internally in winewayland.drv the way you like. But such internal details shouldn't concern other graphics drivers and win32u.