Currently, there is no way to learn of the path-separator character(s) that must be used to separate the components of a path for a given provider, because [System.Management.Automation.ProviderInfo], as returned by Get-PSProvider, has no such property.

In the absence of such information, users may be tempted to assume that \ and / can be universally - and interchangeably - used, which is not necessarily true; for instance, the registry provider only properly supports \, given that / is a valid char. in registry key names - see #5536

Future providers - or even existing third-party providers - could conceivably use completely different characters (of necessity).

Adding a [string[]]-typed .PathSeparator property to [System.Management.Automation.ProviderInfo] would help.

Additional considerations:

• Non-hierarchical providers such as the Variable and Function providers have no real need for a path separator: e.g., Get-Item variable:PSHome works just fine. In practice, these providers follow the FileSystem provider's example and allow interchangeable use of / and \, and tab completion even explicitly inserts these optional chars.: / on Unix, and \ on Windows.

• Third-party implementers of providers will need to provide appropriate values for .PathSeparator too.

• The name to give this new property is debatable, given that the .NET framework has already sown confusion around [System.IO.Path]::DirectorySeparator (the path-component separator) vs. [System.IO.Path]::PathSeparator (the path-environment-variable-entry separator). However, given that the term directory is filesystem-specific and we're talking about abstractions here, my vote is still for .PathSeparator.

Desired behavior

> Get-PSProvider FileSystem | % PathSeparator
\
/

> Get-PSProvider Registry | % PathSeparator
\

Environment data

PowerShell Core v6.0.0-rc