Parameter Naming Inconsistancy: Option vs. Options

PS C:\> New-Variable -Name x -Value 'Read-only variable' -Option ReadOnly
PS C:\> New-Item -Path Function:\xf -Value {'Does nothing'} -Options ReadOnly | Out-Null

Expected behavior

The expected behavior is that both parameters would have been named “Option” (singular) in both cmdlets, regardless of the PS Provider, and whether or not a parameter is dynamic. Were this type of discrepancy found in more places in Microsoft delivered code, even as small as this is, it may have had a largely negative impact on PowerShell overall. I do understand that, “The data stores that the provider exposes can be as varied as Active Directory location and Microsoft Exchange Server mailboxes.” Even so, this seems like a small, non-breaking change. That said, this change would require edits to About Providers, and Function provider.

Actual behavior

“Option” and “Options” are both used for the same parameter on different cmdlets (different PS Providers). Each parameter includes the identical arguments, or parameter values: AllScope, Constant, None, Private, ReadOnly, Unspecified.

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.3
PSEdition                      Core
GitCommitId                    6.2.3
OS                             Microsoft Windows 10.0.18362 
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[iSazonov]

@vexx32 Not binding, I updated my comment. See #3307

[iSazonov]

the code the fix needs to be, no?

I’m not sure yet. I did not find a description in the documentation. This is also a problem. And I did not find this code. Therefore, it is not yet clear what intentions were under the design. Provider code always very sensitive.