Many GUI toolkits for making GUIs for desktops are based on 96 pixels per inch or something similar. Most of these toolkits work well for 1080p and lower resolutions. Now, with 4K and 8K (and my dream resolution of 16K) displays, the amount of pixels involved temporarily exceeds the reasonable settings of these toolkits. That can mean areas of a GUI program that are too small, too narrow, and barely noticeable.
Yes, 4K and 8K resolution is a huge leap beyond in terms of the amount of visual information you can pack into the screen.
I ran into the very directly recently when writing a C++ program using the Fast and Light Toolkit (FLTK 1.3.3). The program logic is such that it dynamically adjusts screen areas based on the overall resolution. It is accurate to say I use a proportional layout approach that resizes various GUI widgets based on percentages translated into pixels. The results are excellent.
Except, you cannot easily control fonts in FLTK. The font size in my program is too small. I can solve it, but not the way I want. In the 1.3.x series of the toolkit, API ease of use and results falls apart in the area of fonts. After a few hours of research I learned there are code libraries from others who ran into the same issues. While they do provide font overrides for FLTK, the situation gave me pause to consider the future. Do I really want extra code at the application level for fonts? Not really. In fact, I am attempting to slim things down.
While I expect native GUI toolkits to adapt (by the way, this is not a problem for certain GUI toolkits for .NET and Java), it would probably be best to have great alternatives that are more adaptable and forward-looking. Alternatives that are heavily vector-based. Some exist, but a few of the ones I saw had issues. This is less of an issue for mobile platforms (phones and tablets) today has they have yet to reach 4K across the board but that time is coming soon.