Thank you very much for the extra information! I was finally able to reproduce this. Here's what I think is happening:
- After the first install, a Private Browsing shortcut is created at startup time. A pref is set in the profile to ensure we never try to create it again.
- Because the Private Browsing shortcut exists, pinning using the Windows context menu works fine.
- The Private Browsing shortcut is removed during the install
- After the reinstall, the same profile is used, and because the earlier pref is set, we don't create a Private Browsing shortcut.
- When the Windows context menu is used to pin this time, there's no Private Browsing shortcut, which causes Windows to create its own with completely inappropriate data.
This is essentially the same bug as https://bugzilla.mozilla.org/show_bug.cgi?id=1762994, except it happens more rarely now because a Private Browsing shortcut exists in the vast majority of cases. For a brief time we were also creating the shortcut in the installer to avoid this exact problem, but we turned that off due to localization issues (https://bugzilla.mozilla.org/show_bug.cgi?id=1790809).
The main reason https://bugzilla.mozilla.org/show_bug.cgi?id=1790809 was an issue was because the way in which we currently check for a matching shortcut is by filename, which means if the installer string and the browser string mismatch, we end up with two shortcuts. This is done to minimize I/O, which was all done on the main thread when it was originally written. Very recently, this I/O has all moved to background threads, so the best option here may be to enhance our shortcut detection. These days, the best option is likely to check the target of the shortcut -- which both points to a specific install directory, and points to a distinct binary for regular and private browsing shortcuts.
Taking this approach would mean turning on shortcut creation in the installer again, which may mean this cannot be fixed until 107 as we're well past the 106 string freeze.