Registry provider: New-Item -Force shouldn't blindly recreate the leaf path component (registry key) #5444
Description
New-Item -Force, at least with the filesystem provider, commendably employs desired-state logic with directories (update: see comment below for why registry keys should be considered the analog of directories, not files):
If the specified path doesn't exist yet, it is created; if it already does, no action is taken (and no error is reported).
By contrast, the registry provider currently blindly recreates the leaf component of the path, which can result in data loss.
Steps to reproduce
# Create HKCU:/foo/bar with value 'baz1'; -Force ensures that ancestral component `foo` is implicitly created.
New-Item -Force HKCU:/foo/bar | Set-ItemProperty -Name baz1 -Value 1
# Now - seemingly - add another value, 'baz2'
New-Item -Force HKCU:/foo/bar | Set-ItemProperty -Name baz2 -Value 2
# List the resulting values.
Get-Item HKCU:/foo/barExpected behavior
Hive: HKEY_CURRENT_USER\foo
Name Property
---- --------
bar baz1 : 1
baz2 : 2
Actual behavior
Hive: HKEY_CURRENT_USER\foo
Name Property
---- --------
bar baz2 : 2
Only baz2 is present, because New-Item -Force HKCU:/foo/bar recreated the bar key, wiping out baz1 in the process.
Environment data
PowerShell Core v6.0.0-beta.9 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.674 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)