In order to get the “channel map”, that is, snapd hits the store with channel set to the empty string (without that the channel map returned would be filtered to only show the requested channel, which defaults to latest/stable).
In this situation the metadata outside of the returned channel map is about the most recent revision that is in the channel map. This is unexpected client-side, but we hadn’t noticed before because the snap client just exposed the metadata from the channel map, and gnome-software (or is it snapd-glib?) didn’t expose the information and (afaict) just used what search returned.
So, the store is exposing unexpected revision information, and snapd and then (snapd-glib and) gnome-software is presenting it to the user.
One possible fix would be to change the store behaviour to always return latest/stable if that channel is open, when querying with channel="". The question is whether this behaviour change will break anybody’s workflow, as it’s a behaviour change. I think it shouldn’t, but we can’t really know.
Another would be for snapd to query the store twice, once with channel=stable and once with the empty string.
A workaround would be for gnome software to use the info from the channel map instead of from outside, but it’s possible there’s info gnome software needs that is per revision and isn’t in the current map.
Thoughts?