The appstream extractor thinks one appstream file may have only one id, equally the snap apps' common-id mapping makes the same assumption. Single id isn't a thing in appstream, and hasn't been for a while: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-provides e.g. ``` <id>org.kde.newname.desktop</id> <provides> <id>oldname.desktop</id> </provides> ``` indicates that the appstream component is also "oldname.desktop" in addition to "org.kde.newname" and provides a means for backwards compatibility. The use case behind this is that if the desktop file needs to be renamed software stores will still be able to resolve the old id (e.g. uris [1]). Additionally this helps with de-duplication of overlapping entires: if the distribution repositories contains an old package which still was oldname.desktop, the software stores will be able to know that a snap providing org.kde.newname is the new variant of it and show the application as one entity as opposed to two with roughly equal data and ultimately referring to the same application (albeit in different package formats). This is a major flaw in the current implementation as this prevents id backwards compatibility. In the yaml schema there ought to be a supplemental-common-id key to list these "old" ids, or common-key needs to be changed to allow an array (with order having meaning so as to differentiate main-id from legacy ids). The appstream extractor then needs to parse <provides> ids and extend the snap.yaml of associated apps accordingly. [1] https://www.freedesktop.org/software/appstream/docs/sect-AppStream-Services-UrlHandler.html