Sorry I still don't see the point. We could speculate how things could have turned out differently if they made different decisions 20 years ago, but that would

Sorry I still don't see the point. We could speculate how things could have turned out differently if they made different decisions 20 years ago, but that would just be it: speculation. If you have some better way to design it that you think could preserve perfect backwards compatibility while allowing the same pace of feature development, you should let them know. Because AFAIK both of those are at odds, no developer can realistically spend time on both for an indefinite period of time, and if there are no new features that anyone wants then backwards compatibility is irrelevant anyway. >Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility Why? Once you decide to refactor an API you have to maintain an extra piece to translate the old to the new, there is no way around that. Developers can spend time before the release working on this translation piece alongside the new features or they can just release it now so people can test the new API before deciding to invest in developing that. For an open source project I can't see how the first option really makes sense, and if your argument is that they should have been developing it the whole time, that is essentially what they were doing for the entirety of the GTK3 development cycle. That is being generous in assuming that it's even possible to do this, sometimes a design is so flawed that you can't even make it work at all with the new stuff. At some point you have decide to cut deprecated APIs or you are left with an infinitely growing pile of technical debt. I referred to this elsewhere, but old GTK1/2 applications that use raw unscaled pixel buffers are an example: there is no backwards compatibility that is going to work here that makes them function correctly with high dpi. It simply cannot work if the application is hardcoded to use an old API that has no concept of dpi or scale and assumes a pixel is always the same size. (Maybe someone can cheat with AI upscaling algorithms but those are usually pretty slow :) I guess to put it another way: I don't see any way that GTK4 could have been designed differently to do something like make it easier to compile GTK1 apps against it while reaping all the benefits of GTK4. If somebody wants to make a GTK1 shim for GTK4 that translates GTK1 API calls into GTK4 API calls, they can go do it now, it would probably be a pain and it's probably not going to magically get you all the new benefits that would come from just porting the application to GTK4 and refactoring to use its new techniques along the way.