(though I now see reg states an incorrect valuetype in its output...)

The registry type is described in drivers docs. It is too specific to have in pwsh.

Nevertheless, here is a list types supported in .Net Runtime. There are more types than pwsh supports: REG_DWORD_LITTLE_ENDIAN, REG_DWORD_BIG_ENDIAN, REG_LINK.
We should add support for them especially since pwsh is now running on Arm.

Thanks, @iSazonov - makes sense to align what registry value types PowerShell supports with what .NET supports.

Separately, however, trying to use any unsupported type should result in an error rather than in quiet failure (and therefore no output).

Separately, however, trying to use any unsupported type should result in an error rather than in quiet failure (and therefore no output).

I agree it could be a non-termonating error, but we silently ignore unknown registry values for years so WG should weight the breaking change.

The .NET docs seem to be incomplete on the types not supported, but they do indicate unsupported types return null (not able to deep link, scroll down to notes). Looking at the code, there are specific types it supports and anything else null is returned.

For PowerShell, it looks like we COULD use GetValueKind() and if it's not in the known supported list (which would have to be maintained if .NET API changes) we return a warning or error. As noted, the current behavior is consistent with 5.1, so it would be a breaking change if anyone is relying on it to return $null instead of an error.

So the most I think can be done is return a warning, but I know users tend to hate those popping up when they didn't used to. So maybe this is a doc issue.

The types are very specific - they are only for drivers. It's unbelievable that someone would write scripts to access such keys - it just doesn't make sense. So this change (non-terminating error) would be formal breaking change.

You can't assume anything about what people might want to use Powershell for. If you do, then large documentation changes would be needed to somehow convey "appropriate use".

Trivial example: comparison of "driver" registry key values between two machines is completely legitimate use of Powershell.

Problem with making it only a docs issue is it weakens the use of Powershell.

At runtime I still won't know the state of the registry, and I could NEVER know - no way to opt-in to even detect unsupported types

It seems a really rather strong appeal to compatibility (with a reduction in the utility of an amazing tool) that new warnings could never be countenanced in any version.