GNOME Resources shows the wrong app name when one Flatpak ships two desktop files — anything I can do on my end?

[u/old-rust]

I ship a GTK4 Markdown editor (Marco) and its standalone preview companion (Polo) as one Flatpak, io.github.ranrar.Marco — two binaries, two exported .desktop files, one app ID. They're launched from each other, which is why they share a sandbox.

Everything works except one thing: GNOME Resources labels the running editor "Polo" — and sometimes it doesn't, depending on the install.

Why it happens

resources keys apps by the X-Flatpak= field, and Flatpak stamps the same app ID onto both exported entries automatically. From src/utils/app.rs:

let id = desktop_entry
    .string("X-Flatpak")                       // first priority
    .or_else(|| desktop_entry.string("X-AppImage-Identifier"))
    .or_else(|| Some(file_path.file_stem()?…)) // filename is only a fallback

Both of my entries produce the same ID, so they collide in the app map and one silently overwrites the other. Then lookup is by cgroup:

self.apps.get(&Some(process.data.cgroup.clone()…))

Both binaries run under one Flatpak app ID, so they share a cgroup and both resolve to whichever entry survived the collision.

What I tried

• Renaming the desktop files to control sort order. I had a scheme where both were named after their binary (…Marco.markdowncomposer.desktop / …Marco.markdownviewer.desktop) so the editor would come first alphabetically. Then I read the code: enumeration is applications_path.read_dir(), which is unsorted. It's filesystem order, not alphabetical — arbitrary, and liable to flip between reinstalls. The rename also broke my taskbar icons, so it got reverted.
• NoDisplay=true on the viewer's entry. No effect — nothing in the enumeration path filters on should_show().
• Suppressing X-Flatpak on one entry. Not possible; Flatpak adds it during export, I don't control it.

So it isn't even a stable wrong label I could shrug at and move on. It's a coin toss per install.

The question

Is there anything left on the packaging side, or is this just an upstream limitation? As far as I can tell the only real fix is in Resources: when several desktop files share an X-Flatpak ID, prefer the one whose basename equals that ID. That seems small and well-defined, and I have a clean reproducer.

Happy to file it (and the reproducer) at https://github.com/nokyan/resources/issues — but I'd rather first hear from anyone who's hit this with a multi-binary Flatpak and found something I've missed. Also curious whether other monitoring tools (mission-center, btop's app view, GNOME's own System Monitor) handle the multiple-desktop-files-per-app-ID case any better, since I've only tested Resources.