Applications absolutely can have breaking changes; one that's bitten me is alacritty changing its config file format in a way that was neither forward nor backward compatible. There are also data file format changes, but those are at least usually forward compatible (new app can open old files, though old app can't open new files, which still could be a problem). But this tension is also a reason that I've started to endorse adding one more number to get marketing.breaking.feature.bugfix versions, where the latter 3 are semver but the first one is arbitrary. If you're a company, let the marketing dept decide how to set that, and if you're a community project do what you like; using the year as the marketing version is fine.

It can, but you do need to decide which dimension(s) constitute a breaking change. IMO, the UI replaces the API as the main dimension in user facing applications, so if functionality is removed from the UI, or significantly altered, then that constitutes a breaking change.

I guess their point is less the support meaning on semver but rather the formatting.

2409a is the same as 24.9.1. But that assumes the 24 prefix is intentional and not accidentally aligning.

Imho I’m ambivalent on it. As long as they use an internally consistent versioning scheme, it’s irrelevant how they surface it.