It's not just setting a new property. Meanwhile, today, you have clients that are dpi aware and are not setting the property. And they all will be out in the wild for an undetermined amount of time (because stuff works for the application developers, why bother?). If you do not handle them anyway, your users will complain that your desktop is broken.
It is just setting a new property. I am not sure we're on the same page here, but if your existing client is DPI-aware, and you just want to let the compositor know it, then it is a one-line change in your client.
As for the "Meanwhile" part, again, how is that better with a new display stack? Unless the point here is that it will be better to just break all those (DPI-aware) clients unconditionally, rather than actually offering them a way forward that does not involve targeting an entirely new display server API.
Because that "meanwhile" takes years. There are still clients that use libX11 ("it works for them") instead of libxcb. libxcb was introduced in 2003.
So "meanwhile" you would have apps that are not DPI aware without flag, DPI aware without flag and DPI aware with flag. And even crappier desktop as you have now for years to come.
The new API is not just for DPI; it is for many reasons, DPI is only one of the issues.
