The Apple way tries to make the DPI change transparent to the application, resizing behind the hood when necessary, and only using integer scales, requiring increased-size assets that are used on-demand.
Windows allows the program to opt into handling the high DPI by itself, obviously producing precise behavior in that case. For compatibility, it will either scale smaller windows up framebuffer-wise, or increase the font size, using the limited resolution independence it has had from the beginning.
In the end, Windows' behavior turned out to be less error-prone. For a little while it seemed like it would be a disaster, pushing the onus onto the developers, but it turned out fine in the end. Personally, I didn't think just making a clean separation like that was the right idea, but I was proven wrong.
Wayland uses the MacOS approach. It allows the program to provide increased resolution buffers at integral scales. This forces fractional scales into framebuffer scaling. The application can't output at a pixel-precise level.
In X11, both of the popular toolkits, Gtk and Qt, simply take the DPI provided and draw widgets bigger, kind of like Windows. It isn't perfect. For example, Gtk only really "supports" integral scales, but themes have been doing dynamic resizing forever, so tweaking the DPI can get perfect fractional sizing aside from some line widths. Older theme engines on Qt might also have a few glitches. But I'm convinced this is definitely the way to go. You're not hiding the fractional DPI from the program. It can be as sharp as it wants.