Note: This issue is just a reminder to reopen #11379 in order to have it revisited by the PowerShell committee; the willingness to do so was signaled in the Sept. '20 community call (see details below), but there was no follow-up, and leaving an issue in a closed state usually means that it falls through the cracks. There is clearly community interest in having this revisited, and the analysis that led to closing the issue is disputed.

Once #11379 is reopened, this issue can be closed.

@SteveL-MSFT

Thanks for discussing issue #11379 in the September community call (https://aka.ms/PSCommunityCall; as of this writing, the September call's recording has not been posted there, but is accessible at https://aka.ms/JoinPSCall, until the next call), starting at 46:00, based on @ThomasNieto's suggestion in the prior solicitation for discussion topics at PowerShell/PowerShell-RFC#260:

(I was hoping to provide a direct link to the relevant portion of the recording, but that will have to wait until it is posted to YouTube and linked to at https://aka.ms/PSCommunityCall.)

Based on your remarks in the recording:

• Given that you indicated willingness to revisit this, please reopen the linked issue and re-tag it as Review - Committee.

• As for your remarks that enclosing variable names in curly braces is a preexisting feature and that people object to having to use them in this case on aesthetic grounds:

  • I don't think anyone here isn't aware that {...} can and sometimes must be used to disambiguate variable names.
  • It is also not about aesthetics, it is primarily about not getting the expected behavior in manner that potentially fails quietly (depending on what strict mode is in effect), due to not expecting to have to use {...} in this case; a secondary concern is typing inconvenience.