^{Follow-up from #7715; related to #7713, #7537, and #5797.}

A pattern is emerging for asking cmdlets to output "bare" objects, which means output objects that:

• are not decorated with NoteProperty members, the way lines read from a file with Get-Content are, for instance.

• are not wrapped in instances of a helper type, the way that Select-String or Compare-Object output is, for instance.

There are three, not mutually exclusive motivations for requesting such "bare" output:

• Improved performance (see Get-Content is slow on large text files. Could it have a parameter to speed it up by not adding NoteProperties? #7537)
• Getting output objects of the desired type directly (see Add a switch to Select-String that makes it return just strings for convenience and performance #7713)
• Getting "untainted" output objects, without NoteProperty members that subsequent processing may act on in an undesired fashion (see ConvertTo-Json: unexpected behavior with objects that have ETS properties (NoteProperty, ScriptProperty) #5797)

There are probably more existing cmdlets that could benefit from the pattern, as would future ones.

In line with PowerShell's commitment to consistency, a common (shared) parameter name should be used in all these cases.

-Bare makes the most sense to me.

To avoid confusion with -Raw as implemented in Get-Content - which simply reads the whole file while still decorating the resulting string - #7715 proposed deprecating -Raw in favor of a more descriptive name such as -Whole. (Note that by deprecating I don't mean to imply removing support for -Raw, just documenting -Whole first and mentioning -Raw as a legacy name).

Environment data

Written as of:

PowerShell Core 6.1.0