It can be more complicated than that, but setting StartupWMClass in that way would handle this correctly assuming: * A .lnk for the executable, and thus a desktop file, already exists. * The .lnk file points directly to the executable, and not to a shell extension or non-executable file. * The executable has a unique base filename that only exists in one prefix. * There aren't multiple lnk files for the same executable, such as one in the desktop and one in the start menu. (Are you able to handle multiple matching .desktop files? This seems like it'd be a common situation.) * The executable does not make use of any modern (>=win7) API's or attributes in the .lnk file to specify the application a window belongs to. An example of this would be an interpreter like python.exe, for which the "application" is the python script being executed.
So, this would be an improvement, and I see no reason it couldn't be done, but I just want to point out that there are a lot of other cases that Windows is able to handle, and Wine could theoretically handle after more work and cooperation, including pinning programs for which no shortcut exists (yet).