Implementing the registry APIs, but backed by a regular filesystem (as Wine does) would be the sensible thing for Windows to do. (I looked at the source of Wine just now and I'm fairly sure nowhere does it process hive files.)
PowerShell exposes the hives as a directory structure, and has for a decade or more. just type "HKLM:" or whatever hive you want and start using "cd" and "dir" all you want.
The guy who implemented that really did a disservice to the filesystem metaphor, though. Instead of making values analogous to files, they're properties of registry keys, so instead of Get/Set-Content, Get-ChildItem, etc. you need to do some gymnastics with Get/Set-ItemProperty to work with them. For example, if you want to find a registry value with a particular name, you can't just do 'dir -rec SomeValueName' to find it like you can on the filesystem provider.
well, the registry has types. files are raw binary data that is almost entirely untyped. how could they possibly enforce typed data without diverging from the filesystem metaphor?
Cmdlets can have provider-specific parameters, so in this case I would add a registry-provider-specific data type parameter with sensible default behavior to New-Item and Set-Content.
For example...
Set-Content hklm:\software\xyz\abc -value 1
...could create a DWORD value by default based on the type of the value argument, while adding '-DataType String' would enable creating a string value.
Files are raw binary data, but a (BTW unreliable) method to understand what they contain has been in use since years: file extensions.
I can see no reason why in a filesystem-like representation of the Registry you cannot have a value.dwd (which is a DWORD), a value.bin (which is a BINary), value.esz, etc., or at least that is what I would use.
