"Alt+Shift+S" is a doubled hotkey at the moment (same as structure tree (structree)). So on hit it opens structure tree and toggles silhouttes, which is not a good behaviour.

So I guess we can just take "Alt+S" as its at the moment only assigned to next tab hotkey (hotkey.tab.next) but it is not used in the session gui,
it is only used in the options and summary gui, that can be toggled by the session's menu but it is a new gui, so it doesn't interfere with the session.

"Alt+S" is also a good hotkey because the Diplomacy Toggle Hotkey is also "Alt+X" and both effecting the silhouttes.

I'd personally favour a solution where we didn't have to reassign other hotkeys.

The reason I suggested "Alt+Shift+T" was that the letter choice made some sense on some level ("T" for "tree"). (And FWIW it is attainable with one hand for me, although I am aware that some players may not be as dexterous.)

Of course, there's no reason why there has to be a hotkey - the structree is not an essential gameplay mechanic.

(
As far as I understand the PushGuiPage function introduced in rP14496, the callback argument of PushGuiPage means that the given function is called after the GUI page to be opened is closed; i.e. it not being optional for the page to call the callback function.

I see this belief manifested in msgbox.js, summary.js, civinfo.js, manual.js, options.js, core.js, structree.js where we find this pattern:

if (data.callback)
Engine.PopGuiPageCB(i);
else
Engine.PopGuiPage();

But here the callback is skipped because that happens to fit the pause/resume necessity.

Having the child GUI page able to decide to skip the parent GUI pages callback handler means that the parent GUI page has no chance of being certain that the callback function is called regardless of what the child GUI page computes.
Always executing the caller would also mean one could unify PopGuiPage and PopGuiPageCB, merge all above cases, but also has to remove the pop call from this switchToStrucTreePage function and add the push call to the mainmenu, gamesetup and session gui page...

Merging the structree and civinfo page would prevent the problem but not solve it.
So it seems like undesirable code but unsolveable if one wants to keep the feature.
)

A proponent of civ persistance might propone civ persistance when switching from gamesetup to session.
An opponent of civ persistance that argues based on undesirable code traits might oppose civ persistance in the other two pages too, as they add the same code traits.

1.2. Duplication: Storing this in the caller GUI page means having to copy the state variable and callback function to every GUI caller (that's 2 or 3 pages for now but maybe extended in the future), making it timeconsuming to maintain and more prone to coding errors. (I run into this effect for example when changing the GUI Push/PopGuiPage callback handling from rP14496, but the problem is systematic)

However I don't see an alternative other than:

using the Config system (regardless whether its written to the disk or not).

hiding the page instead of closing it, so that the page doesn't lose it's state, keeps all state as local as possible and GUI pages remain agnostic of each other