The content interface IDs were chosen based on an assessment of the compatibility issues you bring up. I don’t think it is appropriate to tag any of them with a reference to a particular base snap: I’d expect that apps built using core, core18, or a future Fedora base snap would all use the same theme data.
Icon themes consist of a set of image files, an index.theme file holding metadata described here, and optionally an icon-theme.cache file described here. These formats have remained stable for longer than Ubuntu has existed, and there are multiple independent code bases relying on the layout and file formats. I don’t expect it to change any time soon.
Sound themes are a more recent development, but again rely on a specification similar to icon themes and not linked to a particular toolkit or even a particular build of a particular toolkit.
GTK themes underwent a dramatic change with the release of GTK 3.0, switching from a combination of binary “theme engines” and custom configuration files, to using CSS. So gtk3-themes seemed to be the right amount of versioning for the interface ID. We don’t know what changes will be required with GTK 4. If we ever try to address GTK 2 themes, it will have to deal with all the problems inherent with native code plugins.
Now it is true that themes do get updated with new GTK minor releases. These are usually handled by theme authors in one of two ways:
- add new CSS rules to the theme that aren’t matched by the old GTK release.
- split the theme into a new and old version. For instance, Ubuntu’s Ambiance theme provides
gtk-3.0/gtk.cssandgtk-3.20/gtk.cssin it’s theme folder: the first used by GTK < 3.20, and the second used by everything newer.
While (2) might sound like a reason to have more strongly versioned interface IDs, not every theme does this and not every theme that offers version specific CSS splits on the same releases.
Also, when a theme decides to try and offer different behaviour based on GTK version, the different versions are rarely independent. They might reference the same image resources, or even import common CSS files. So I think we are best served to just have a single gtk3-themes slot.