Exercise 3: Get-ChildItem vs. Get-ItemProperty — Possible Solution
====================================================================

WHY GET-CHILDITEM CAN'T SHOW A REGISTRY VALUE
------------------------------
Get-ChildItem lists a location's CHILDREN. In the filesystem, a folder's children are the files and subfolders inside it - a natural fit. In the registry, a key's children are its SUBKEYS, not its values. A value like ProgramFilesDir isn't a child of the CurrentVersion key the way a file is a child of a folder - it's a PROPERTY attached directly to the key itself. Since Get-ChildItem only ever lists children, it will show subkeys underneath CurrentVersion but will never show ProgramFilesDir, no matter how the command is run.

THE CMDLET THAT IS NEEDED INSTEAD
------------------------------
Get-ItemProperty is the cmdlet built specifically to read an item's own properties/values rather than its children - Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion -Name ProgramFilesDir correctly returns the actual value.

THE UNDERLYING REGISTRY CONCEPT CAUSING THE GAP
------------------------------
The registry's own key-vs-value split doesn't map cleanly onto the filesystem's folder-vs-file split that Get-ChildItem was originally modeled on. A registry key can have both subkeys (children, like a folder's contents) AND values (properties attached to the key itself, with no filesystem equivalent) at the same time - the chapter describes this as the provider abstraction being "genuinely leaky" at exactly this point.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that Get-ChildItem only lists children (subkeys), correctly identifies that a registry value is a property rather than a child, names Get-ItemProperty as the correct cmdlet, and correctly attributes the gap to the registry's key/value model not matching the filesystem's folder/file model.