I did not have a backup. ClassicShell has never lost a setting before so I never bother.
Ah, I thought "didn't use to work" might have been the case but I couldn't remember. In which case I amend my bug report to "Skin menu is inconsistent with the rest of the settings UI". The Skin settings really did get lost though.
ClassicShell correctly guessed that I was using classic style, so I would have expected all the settings to carry over. So that does not explain the behaviour.
Edit:
To be fair, I don't see how the fact that the Skin settings are stored in one key vs doing something else means that the "bold to indicate non-default" feature doesn't work. Load the key, and if the settings are different from the hard coded defaults, bold the items.
Hm. I seem to recall that the bolding shows up until the option is specifically reset to default, regardless if the option is set to a default or non-default value. That implies to me that the bolding is triggered off the mere presence of a registry entry, instead of triggered off the value.
If that's the case, please consider changing that so that only non-defaults are bold. I never understood the rationale for bolding a default value just because it had manipulated.
Edit 2:
Examining the registry it looks like 3.8.0 used to stored the settings right in the top-level ClassicStartMenu key, but 4.0.0 stores then in ClassicStartMenu\Settings with a version item. Here are the old and new Skin items:
ClassicStartMenu: Skin1:REG_SZ:Smoked Glass Skin2:REG_SZ:<No Skin> SkinOptions1:REG_SZ:DA60029A|E55CEDD2|BD80CDB2|C26EAF5C|86F3669C|5225DC46|5D3248DD|1FC64124|5EA361A2| SkinOptions2:REG_SZ: SkinVariation1:REG_SZ: SkinVariation2:REG_SZ:
ClassicStartMenu\Settings: SkinC1:REG_Z:Smoked Glass SkinOptionsC1:REG_SZ:BD80CDB2|C26EAF5C|86F3669C|5225DC46|5D3248DD|1FC64124|5EA361A2| SkinVariationC1:REG_SZ:
|