Steps to reproduce

# Create a variable name that is nothing but spaces:
${ } = 'boo'
${ }

# Create a variable name that contains leading or trailing whitespace:
${   foo   } = 'bar'
$foo # Not found
Get-Variable -Name '   foo   ' -ValueOnly

# Create a function whose name contains leading whitespace (trailing whitespace is silently stripped)
New-Item 'function: foo ' -Value {'Whitespace only'}
& ' foo ' # Not found
& ' foo' # This works (the trailing whitespace was ignored during creation of the function)

# Create an alias whose name is nothing but whitespace
New-Alias -Name ' ' -Value Get-Date
& ' ' # Shows the date

# Set a breakpoint on a command that is just whitespace
Set-PSBreakpoint -Command ' '

# Try to trigger a breakpoint on that command
& ' ' # Does not work

# Set a breakpoint on a variable that is just whitespace
Set-PSBreakpoint -Variable ' ' -Mode ReadWrite

# Try to trigger a breakpoint on a variable whose name is nothing but whitespace
${ } # triggers breakpoint

# Create a filename in the current location that has leading and trailing whitespace in its name
New-Item ' huh.txt ' -Value 'Explorer does not allow such names to be created'

# Open the file in notepad
notepad ' huh.txt ' # works
notepad ' huh.txt' # also works even though the trailing whitespace was dropped
notepad 'huh.txt' # does not work; prompts to create a new file

Expected behavior

1. Command and variable names should either be trimmed so that they contain no extraneous whitespace, or they should raise an error if they contain extraneous whitespace so that there is no ambiguity on the part of the person creating the command or variable.

2. Set-PSBreakpoint should trim whitespace from string parameters.

Actual behavior

As indicated in the comments above.

How we might fix this

Define an AutoTrim attribute

This attribute would automatically trim string values before they are validated against validation attributes. That corrects the contents for commands, which is helpful; however, it means users can pass in values and get results that are different than those values (i.e. create an alias with leading/trailing whitespace and end up with alias that doesn't have the whitespace). This could hide bugs that exist in calling code.

Define a ValidateNoExtraneousWhitespace attribute

This attribute would result in an error in the parameter binder if a parameter of type string or a parameter that is a collection of type string contained strings that included leading or trailing whitespace, forcing the caller to deal with the problem. This is my preferred partial solution to this issue.

Questions

Is there anything we can/should do about provider paths with leading/trailing whitespace? For PowerShell entities such as functions/aliases/variables, we can obviously generate errors if leading/trailing whitespace is used, but since files exist outside of PowerShell and can be created with spaces in Windows (not sure about macOS/Linux, haven't tested there), we probably can't provide a generic solution that prevents use of paths with extraneous whitespace.

Environment data

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