`ValueFromPipelineDictionaryName` and `ValueFromPipelineDictionaryValue` parameter attributes

Summary of the new feature / enhancement

Adding a ValueFromPipelineDictionaryName and a ValueFromPipelineDictionaryValue parameter attribute could help towards a
common approach to enumerate dictionaries for processing at run-time. This prevents a new iDictionary parameter and required parameterset exclusions

Proposed technical implementation details (optional)

Wishful thinking (for cmdlets along with Set-Item):

param(
    [Parameter(ValueFromPipelineDictionaryName=$true, ParameterSetName='Path', Mandatory=$true, Position=0, ValueFromPipelineByPropertyName=$true)]
    [string[]]
    ${Path},

    [Parameter(ValueFromPipelineDictionaryValue=$true, Position=1, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)]
    [System.Object]
    ${Value},

    ...

Pipeline

In case of a Pipeline input, it will divide the name and value of each dictionary item to respectively the Path or Value parameters.

Example: (Wishful thinking)

Set-Location -Path "ENV:\"
$HashTable = @{ DEMO_CLIENT_ID = "ff3b7b84-e041-4e76-993e-239930808aa7"; MyPath = "C:\MyPath" }
$HashTable | Set-Content

Argument

If supplied as an argument for either Name - or Value parameter it will bind both parameters to the respective parameters that contain the ValueFromDictionaryName and ValueFromDictionaryValue parameters.

Example: (Wishful thinking)

Set-Location -Path "ALIAS:\"
Set-Item -Path @{ np = "c:\windows\notepad.exe" }

Consequently, an error is expected when either of the parameter is assigned twice, e.g.: (in the above Set-Item example:

Set-Item -Path @{ np = "c:\windows\notepad.exe" } -Value 'Word.exe' # Should error
</strike>

The issue names no files, tests, or entry points. Start by locating PowerShell's parameter-binding and dictionary pipeline handling, then define the intended behavior for the two attributes and verify it with tests covering dictionary names, values, pipeline input, and conflicting bindings.