Ah, thank you Eli. I had not yet looked into the Emacs source to determine that. But I'm glad it's already there. Much more knowledgeable developers have been at work. :) I see emacsclient.c, runemacs.c *and* w32term.c all call SetCurrentProcesExplicitAppUseModelID with L"GNU.Emacs". So it should work.
Though I do see the problem in Windows 7 too (not just Windows 8 or 10).. I believe the issue is that by default, when pinning Emacs, the shortcut that gets created does *not* have the AppID set, and therefore looks different to the Windows shell. I don't know if pinning other applications would get the correct AppID or not - and if it does maybe Windows is looking for something in the exe that it's not finding in emacs.exe to create the shortcut with the AppID.
There is a tool called 'lnk-parser' which could also be useful. <https://code.google.com/p/lnk-parser/
> It's a command-line tool that dumps the contents of a shortcut (lnk file) and includes the AppId. And I just tried this test. I ran lnk-parser on my (working) pinned Emacs shortcut and it shows the AppID of "GNU.Emacs". I unpinned it, ran runemacs and pinned it again, and now the lnk-parser shows that the shortcut does *not* contain any AppID.
Maybe there's a way to help Windows create the shortcuts correctly when pinning by providing other info in the emacs processes, or we can write a program like win7appid that can be used similarly (and GPL'd) to let users manually update the shortcuts.
Another way to (manually) edit the app id of a shortcut... add the following string registry entry to HKCR\lnkfile:
Then doing the Properties on a shortcut file, in the Details tab, the AppUserModelID is displayed - and is editable. I fixed my repinned emacs shortcut with this. (You could just set "FullDetails" to be *just* "prop:SystemAppUserModel.ID" but then the details tab will *only* show the app id.