The Gnome Maps window currently has the following WM_CLASS:

WM_CLASS(STRING) = "gnome-maps", "Gnome-maps"

The desktop file name installed is: /usr/share/applications/org.gnome.Maps.desktop

Further, the .desktop file doesn't include a StartupWMClass=Gnome-maps to deal with this mismatch.

This mismatch makes standards-compliant desktop environments unable to identify the application backing the window and track it properly.

This is supported by Gnome 3 documentation available at: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased

Relevant excerpts:

> To ensure the GNOME 3 Shell will track your application, you can also set the WM_CLASS X window property to be the same as your application's .desktop file name, without the .desktop extension (the desktop file should be lower-case).
> The easiest way to achieve this is to have your application's process name match the .desktop file name, and ensure you use g_option_context_parse.
> [...]
> WM_CLASS(STRING) = "chromium-browser", "Chromium-browser"
> The second item here is the WM_CLASS. Chromium-browser (when lowercased) matches the chromium-browser.desktop as we want.

Plasma and Unity work the same way.

So either:

a) WM_CLASS is set to the .desktop id properly (this would also align well with the Wayland appid window property, which is specified the same way)

or

b) the installed .desktop file needs a StartupWMClass

This is likely a more general problem beyond just Gnome Maps, but as I know the stack poorly, I chose to file it as a concrete, application-specific example. Please move as required.