Solution reload restores wrong tab state for .ino (fewer tabs, pin lost) and then Duplicate Tab fails

Environment: Visual Studio 2026, version 18.10.1, Visual Micro (vMicro) extension 2026.708.2204, Arduino project.

Steps to reproduce:
1.      Open the main .ino file of a Visual Micro Arduino project and duplicate it, so that two (or more) tabs of the same .ino file are open.
2.      Pin one of these tabs.
3.      Save and close the solution (or close Visual Studio) with those multiple tabs — one of them pinned — still open, so the window layout is persisted.
4.      Reopen the solution.

Expected result (step 4): The same number of tabs of the .ino file is restored, and the previously pinned tab is still pinned.

Actual result (step 4): One fewer tab is restored than was open before closing (e.g. 2 tabs → only 1 after reopen), and the remaining tab is no longer pinned, even though it was pinned when the solution was saved.

5.      With the solution now reopened in this (incorrect) state, try Window → Duplicate Tab or tab context menu → "Duplicate As New Tab" on that file.

Expected result (step 5): A new tab/view of the file opens.

Actual result (step 5): Nothing happens — no new tab is created, no error or notification is shown.

Workaround found: If, after reopening, you close the remaining tab(s) of the file so that exactly one tab is open and then reopen the file fresh from Solution Explorer, Duplicate Tab starts working again normally.

Additional info: This only affects .ino files opened through Visual Micro's custom editor/document handler — .cpp files are not affected. The pattern (tab count restored incorrectly, pinned state lost) strongly suggests vMicro's .ino document/tab-tracking state gets corrupted or desynced during the save-and-restore of the window layout when multiple tabs of the same .ino file — one pinned — are involved, and this stale/incorrect internal state is what then blocks Duplicate Tab from working until the tab is closed and reopened cleanly.

Thanks for looking into it. To confirm: I always open the solution via the VS Start Window → clicking the solution in "Recent" — I'm not using "Open Arduino Project" for this (that was only used once, for the initial import). So it's the standard VS reopen path you described.

One thing that makes me hesitant to write this off as pure VS behaviour, though: in the exact same solution, .cpp files restore and duplicate correctly every time, even with multiple tabs and a pinned tab — it's specifically the .ino file(s) that lose a tab and lose the pinned state on reload, and only then does Duplicate Tab stop working on them. If VS were handling 100% of this with no vMicro involvement, I'd expect .ino and .cpp to behave identically, since after the initial project creation they're supposedly "just" files in a standard C++ project. The fact that only .ino is affected is what made me suspect something in how vMicro's .ino editor/document handling differs, even if it's subtle (e.g. it might still register a custom editor factory or file-type association for .ino that VS treats slightly differently during tab persistence).

Happy to provide anything else that would help — screen recording of the exact steps, etc. Let me know what's most useful.

Yes, I disabled the Visual Micro extension via Extensions > Extension Manager, restarted the IDE, and opened the solution — but I still can't add/duplicate a tab. So it doesn't seem to be caused by Visual Micro's .ino registration.

A few more details that might help narrow it down:

If I close the solution and reopen it, I have one fewer available tab than before (the limit seems to shrink each time the solution is closed/reopened).
If I fully restart Visual Studio, then after opening it lets me add exactly one tab — and after that, no more.

So it looks less like a fixed "duplicate doesn't work at all" issue, and more like there's some internal counter/limit for tabs that starts low, allows one duplicate right after a fresh restart, and then decreases further (or gets exhausted) with each solution close/reopen — independent of whether the vMicro extension is enabled or disabled.