Ok, but HyperHDR logs would be more helpful as it's using not IDs but device/output names.

sorry, I meant the device name, like the \.\DISPLAY1.. or is it something else?

HyperHDR uses 2 parts/names in the final approach. But there's no point in theorizing because if the problem occurs there, I just want to see what the system reports and whether it's a matter of the enumeration changing for a moment because one of the monitors was absent when HyperHDR started the grabber.

Sorry, I think were talking at cross purposes. The Issue Im seeing is not something that happens when coming back from sleep, Its just that when booting Windows the displays get different names most of the time. This is not the fault of HyperHDR, but just Windows.
I can completely restart HyperHDR as often as I want, and it will still be consistently wrong between restarts, but as soon as I reboot, it can be different, but still consistent during that boot cycle.
I sure can test something on that version, but Im sorry, I didnt understand what really I should test, as restarting the Grabber or HyperHDR completely will just pull the same IDs/names it did before? Im not starting HyperHDR at boot too, just manually.
If I misunderstood something, Im sorry, just let met know :)

It seems to me that if one monitor is missing, Windows can temporarily change the order of all of them. For example, if they were Display1, Display2, and Disyplay3, the next time after restart, if Display1 was missing for a moment when HyperHDR was started, it changed Display2 => Display1 and Display3 => Display2. Or Display2 => Display2 and Display3 => Display1 - it doesnt matter. I just wanted to verify this. However, if you're saying this isn't the case, I don't think anything can be done since it doesn't even allow me to obtain monitor serial numbers or other permanent identifiers, and everything else is just half-measures for specific use cases, which I'd rather not bother with.