None of which required breaking backwards compatibility as demonstrated by "Linux, Windows, OpenJDK, Clojure, Emacs, or FLTK" (and I'll add Xorg too). You can add new things without breaking old things.
> That just isn’t true, you clearly haven’t used GTK. FLTK has never done core redesigns like GTK.
One, I've wasted 6 years of my life writing GTK 2 and GTK3 apps. Two, What does "core redesigns" have to do with breaking backwards compatibility? Did the redesign necessitate removing GtkStatusIcon for example^1? What about ANY of the breaking changes made?
1: The reasoning given to justify breaking compatibility here paints a more clearer picture of how GTK devs treat breaking backwards compatibility. Remember, this is coming from the developers of what is supposedly a cross-platform toolkit.
A core redesign of GTK2->3->4 was moving from a model built around X11/xlib to one built around Wayland. GtkStatusIcon only functioned correctly on one backend, X11. It was very poorly supported on win32 and macOS.
Other clear examples that had to happen was all rendering used to be done on the CPU with Cairo as part of the API. Cairo is very slow on high resolutions, or when doing animations, or just in general. The modern GTK is built around GPUs using OpenGL. There is a backwards compat story, in that you can use Cairo yourself still, but the API is all around modeled with modern hardware in mind. Something FLTK clearly is not and as such it cannot accomplish much of the things GTK4 can in terms of hidpi, animations, shaders, styling, zero-copy rendering, multimedia playback, etc.
Yes, if given infinite resources, one could both resdesign a library and not break API, but it is a small group with limited resources.
I genuinely think they have done an incredible job and there are many new possibilities with the toolkit now that were not previously.
If the argument truely is just "never break API" I fundamentally disagree and think most platforms that follow it are bad platforms full of legacy cruft.
GTK4 is very nice.