ShowSuperHidden, as we discovered, controls whether super-hidden (Hidden + System) files are displayed. As far as I can tell,
SuperHidden controls nothing and its existence is probably a programming error.
Using Process Monitor, I observed reads from and writes to these Registry values. The only interaction with
SuperHidden was a write when the user opened the View tab of the Folder Options dialog. It received a 1 if super-hidden files are displayed, 0 otherwise. It was never read, even when I terminated and restarted Explorer.
Procmon provides the stack that led to a monitored operation (double-click an event and consult the Stack tab), so I examined the DLL files involved using IDA v5.0. The only relevant one with a mention of
CachedShellState::SaveAdvancedSettings function issues a Registry write to that value and others in that key, committing the current view settings.
Explorer apparently calls that function before showing the View tab. That's probably done to make sure the Registry is consistent with the current in-memory settings before loading the current state of the View options, though I admit I'm not 100% certain on the reasoning. Anyway, the corresponding
CachedShellState::_GetAdvancedSettings issues a read from the correct value,
These disassembly listings are from the Windows 7 version of that DLL. In Windows 10,
SuperHidden does not exist in the Registry, and
CachedShellState::SaveAdvancedSettings writes to
Therefore, I conclude that when programming the version of that function that comes with Windows 7, a developer mistakenly omitted the
ShowSuperHidden, but the error was corrected along the way to Windows 10.
For the curious, the Folder Options dialog isn't broken by this error because it consults the
ValueName entry under each setting key here:
Working out the significance of the other parts of that branch is left as a (fun!) exercise to the reader.