I agree, resolution independence should be a higher priority for macos. They've been able to dance around the subject by just doubling everything and calling it retina, but true accessibility would allow everyone to set the scale that works best for them.
Resolution control on my mac mini + 3rd party 4k monitor works just great, you can choose to have native resolution, 'retina' (i.e. 2x scaling), or a few steps in-between the two, there's plenty of flexibility.
Plus, the way it works means that (as I understand it), programs don't really need to do anything to support all these variations. Behind the scenes, the OS renders everything at a very high resolution, then uses the graphics hardware to smoothly scale everything down to your chosen size.
My eyes aren't good enough to use the native resolution, and using the 'retina' setting wastes too much screen real estate (I mean, that's why you buy a big monitor for, right?), so having somewhere between the two is essential. I was concerned that choosing a non-simple scaling (neither doubled or native) would make things blurry or slow, but it just works, and works well. Even dragging windows between a high-DPI and normal DPI display is seamless.
As an aside, after years of using a low-res monitor, with tiny fonts to squeeze as many terminals and emacs windows onto my screen, high-DPI is a godsend. For a long time after getting the 4k monitor, I'd just play around with the mac's screen zoom accessibility function (uses the mouse wheel to smoothly zoom into an area of the screen) - it was astounding to me just how much you can zoom before individual characters become blocky. They used to be drawn as 8x8 pixels and now, to my aging eyes, each letter looks as smooth and detailed as printed text!
It's not as simple as fixing the display setting code. For example WebKit is not happy with non-integer DPRs. It will leave gaps here and there. When those gaps happen is probably rare enough that it's not a show stopper but I suspect lots of other MacOS software has similar issues.
Another tangentially related issue, how do you display a pixel perfect image on a non-integer DPR. For example lets say you want to show 8bit mario in HTML at exactly 16 or some multiple of 16 pixels so that there's not odd integer scaling. it's quite a pain, requires JS, and requires flexible page layout since you won't be able to use "CSS pixels" to decide the size to display it. Possibly that's an argument for never having non-integer DPRs.
You're right it's not simple, it would require a refresh of uikit and a transition period for developers to learn how to opt in or opt out. There are existing ui frameworks like what android provides that show how to define ui elements, strokes, padding, margins, and text to use either scaled pixels or fixed pixels.
Leave everything as fixed pixels for backwards compatibility and add scaled pixels in for new development. I can guarantee that if Apple ported the main apps like Finder, Mail, Safari, Calendar, Music to support resolution independence that other developers would jump on board quickly to keep up to date.
