The fragmentation on Linux desktop causes a lot of churn, both in users looking for more cohesive desktop experiences, and on developers looking to not having to deal with all this mess.
In regards to major backwards-incompatible version changes, to me it's pretty clear that many developers simply don't give enough priority to maintaining backwards compatibility. Most cases i've seen of backward-breaking changes were unnecessary: the new features could've been added while maintaining the existing APIs (maybe deprecating them if needed). The decisions to not maintain the existing (and now deemed "old") APIs were not done on a technical ground, but more on an ideological/purist ground, where the "old" APIs were considered "bad" or too costly to maintain (both claims totally subjective and not supported by much evidence). And simply not enough thought was put in considering how users of the APIs may find it difficult to do a major version update, or might simply churn away and not do the update or look for an alternative.
Now, i don't have direct experience with GTK, so i might be totally bullshitting and maybe nothing that i said applies to GTK major version bumps. But the fact that so many projects find it hard to update and are stuck on older versions for long times, and that the desktop UI paradigm hasn't changed that much in the last 20 years (how much MUST the APIs for windows and UI controls change then?) makes me suspect that there is at least a bit of that backwards-compatibility disregard here too.
I didn't try to codify a few little ideas I had into Linux UI apps purely because all the drama with Gnome and whatnot. I don't have time for this bullshit. Terminal apps can be written once and just work(tm). Linux GUI development has always been for people that have no life.
The fragmentation on Linux desktop causes a lot of churn, both in users looking for more cohesive desktop experiences, and on developers looking to not having to deal with all this mess.
In regards to major backwards-incompatible version changes, to me it's pretty clear that many developers simply don't give enough priority to maintaining backwards compatibility. Most cases i've seen of backward-breaking changes were unnecessary: the new features could've been added while maintaining the existing APIs (maybe deprecating them if needed). The decisions to not maintain the existing (and now deemed "old") APIs were not done on a technical ground, but more on an ideological/purist ground, where the "old" APIs were considered "bad" or too costly to maintain (both claims totally subjective and not supported by much evidence). And simply not enough thought was put in considering how users of the APIs may find it difficult to do a major version update, or might simply churn away and not do the update or look for an alternative.
Now, i don't have direct experience with GTK, so i might be totally bullshitting and maybe nothing that i said applies to GTK major version bumps. But the fact that so many projects find it hard to update and are stuck on older versions for long times, and that the desktop UI paradigm hasn't changed that much in the last 20 years (how much MUST the APIs for windows and UI controls change then?) makes me suspect that there is at least a bit of that backwards-compatibility disregard here too.