It is exposed reliably already, it is just that to get workable mixed mode HiDPI support (i.e. multiple monitors of different DPIs) you need the window manager and toolkits/applications to cooperate:
1. The toolkit/applications needs to support scaling, preferably using arbitrary (aka fractional) scaling.
2. The window manager needs to obtain per-output (output=monitor) DPI and associate a scaling value for each output (note that scaling and DPI are not necessarily tied - someone might e.g. want a high scaling factor for a secondary 1440p monitor because they have it farther away than their primary monitor).
3. The application/toolkit needs to tell to the window manager that it supports scaling as well as know that the window manager supports scaling. Window properties can be used to do that.
4. The window manager needs somehow to communicate to the toolkit/application to scale a window. This can happen either because the window was dragged to a monitor (output) with different output but it could also be because, e.g. the user explicitly requested to scale a window from the window menu (e.g. for making a screencast for youtube). This "somehow" is basically a set of messages since the mechanism is already used for other things already.
5. If a toolkit/application does not support scaling (i.e. it does not have the appropriate properties) the window manager may decide to fake it itself (e.g. by redirecting the window output to a pixmap and then drawing that pixmap scaled). If a toolkit/application does support scaling but the window manager doesn't then it is up to the toolkit/application to decide, e.g. it may do its own scaling by tracking the output the window is and scaling itself appropriately (this will need some heuristics to avoid being too janky as the toolkit/application is essentially taking over part of what the window manager's job and toolkits/applications may just not want to do that).
If it isn't already obvious, the issue here is that this concerns multiple entities:
1. There needs to be some sort of commonly accepted messages and properties for the window managers and applications to communicate scaling.
2. Toolkits (and applications that use custom toolkits) need to implement support for scaling and handling the above messages and properties.
3. Window managers also need to implement the above messages and properties, implement some sort of scaling configuration and use the appropriate RandR functionality to setup initial per-output scale configuration.
AFAIK of all the above the only thing that exists is that the X server can provide the necessary information and Qt supports fractional scaling. AFAIK it also can use its own root property to set per-output scaling but it does the scaling itself independent from the window manager so it is far from ideal.
For the rest basically the toolkit and window manager developers need to be convinced to work on it and also come up with a common message/property protocol, both of which IMO are the hard parts - compared to that, the technical side is easy :-P.