In Windows Taskbar Settings, I have the “Combine taskbar buttons” option set to “Always, hide labels.” For many Windows apps, if the app is “pinned” to the taskbar, starting a new instance of the app will populate the existing taskbar button with a “child” button that “flies out” when the cursor hovers over the taskbar button and which corresponds to the new instance of the app. Starting another new instance will populate the same taskbar button with a second “child” button, and so on.
With Rhino up through version 7, starting a new instance of Rhino does not populate the existing taskbar button with a “child” button but, instead, instantiates a new taskbar button and populates that button with a “child” fly-out button corresponding to the instance of the app. Starting another new instance of that version of Rhino will now populate this new taskbar button with another “child” button.
It’s mildly annoying that instances of Rhino don’t populate their “child” buttons to the pre-existing taskbar button the way that, for example, Microsoft Excel does, but, new in Rhino 8, the behavior is even more annoying. First, I should tell you that I have side-by-side Rhino installations and that, sometimes, I will launch instances of multiple versions of Rhino at the same time. Previously when I did so, I would get a new taskbar button for each version and subsequent additional instances of that version would populate to the corresponding new taskbar button as “child” buttons thereof. Mildly annoying but tolerable. An instance of Rhino 5 and an instance or two of Rhino 7 and I’d have a new Rhino 5 taskbar button with one “child” button and a new Rhino 7 taskbar button with two “child” buttons. Not ideal, but not a deal breaker.
However, with Rhino 8, things are different. Rhino 7 and Rhino 8 seem to have an identity crisis: Whichever of those versions I launch first creates a new taskbar button that becomes the default “parent” button, and subsequent instances of either version will populate as “child” buttons to that “parent” button.
For example, if I open an instance of Rhino 7 I get a new Rhino 7 taskbar button. If I then open an instance of Rhino 8 I do not get a new Rhino 8 taskbar button but, instead, the Rhino 8 instance populates as a “child” to the (new) Rhino 7 taskbar button. The first few times that happened I simply thought Rhino 8 had failed to load (I do other things as Rhino is loading so, frequently, the newest instance of Rhino is not in the foreground when it finishes loading). I saw the splash screen, then the splash screen went away and I worked on the prior instance of Rhino (or whatever), and when I went to find my Rhino 8 via the expected, new taskbar button it was nowhere to be found. So I started Rhino 8 again; when I finally figured out that Rhino 8 had, indeed, loaded, I had five or six instances of Rhino 8 “hiding” behind the Rhino 7 taskbar button! (Yes, I can be slow to catch on sometimes!)
Similarly, launching Rhino 8 first gives me a new Rhino 8 taskbar button behind which new instances of Rhino 7 and 8 will both populate their “child” buttons.
I know you’re already up late working on important yet ill-defined user wants for e.g. one-button instantiation of logarithmically spaced polar arrays of Bugatti Bolides randomly colored in each of the full spectrum of colors of the Pantone color gamut (raytraced, and zebra-striped to prove >G2 continuity of all blends and fillets, of course), but could you please take a look at the Rhino taskbar button conformity with what once might have been a Windows “User Interface Best Practices” white paper topic before SAAS and pop-up advertising took over the desktop app world?
Thank you. At least one doddering old person will appreciate it if you succeed in fixing this, or even just get Rhino 8 and Rhino 7 to stop piggy-backing on each other’s taskbar buttons. 
