1. Start Nightly with a new profile using the -P command line switch.
2. Go to Options, and check General/Startup/Restore Session State.
3. Press Ctrl+N to open new window, then Ctrl+B to open the sidebar (or Ctrl+H, reproduces too). At this point, the active window's sidebar is open, but the original window does not show a sidebar.
4. Press Shift+Ctrl+Q to close Nightly.
5. Open the same profile again.

Observed: Both windows show sidebars.

Expected: Sidebar open/close configuration is retained per-window.

This is a regression in Nightly. The problem did not happen just a few days ago. I cannot tell exactly when, but I am using sidebars quite often, and usually have 5-6 windows open and, being a Nightly guinea pig, restart a few times daily, so I have a reason to believe I would have noticed.

Also, this does not reproduce the other way round. A closed sidebar in the active window does not reset per-windows sidebar state of other windows. Non-repro:

1. Repeat steps 1 and 2.
2. Open five more windows.
3. Open the sidebar with Ctrl+B.
4. Quit Nightly
5. Restart session. Observe that all six window have sidebars.
6. Close sidebar in the current window. Select another window and close the sidebar in it too, for a good measure.
7. Quit Nightly while that window is active, and start it again.

Observe that the sidebar open/closed state has been retained: the active and the other window have their sidebars closed, and four windows have their sidebars open.

Prior art: There was a similar but not quote same bug #1391280, but it has been marked as fixed between 57.0a1 and 57.0b7. #1406824 describes same behavior, but it was deemed a consequence of #1391280, as I understood. So the issue I am reporting is apparently new.

Confirmed with 20190218094427

Issue was reproduced using the latest Nightly build.
Tried to find a regression using mozregression with no luck, issue doesn't seem to be a regression since it reproduces on older Firefox builds from 2014.

Yeah, we don't preserve unique identifiers per opened window and tie its enabled features to that so that restore goes back in-order.
Perhaps we should treat these feature-restores more like pinned tabs. Something to work on in the future, for sure.