Powershell: Decide on which experimental features will remain in experimental in 7.1

[joeyaiello]

As we did with 7.0 in #11302, we have to make a decision going into RC on whether experimental features are "graduated" to stable vs. staying as experimental.

Per some conversations with the @PowerShell/powershell-committee, this is our current position on each (edited 8/25/20: the below are now the current plan-of-record for 7.1):

Supported / Non-Experimental

• PSNullConditionalOperators: We agree that braces for variable names are an existing PowerShell construct, and they work fine here. This hasn't caused issues, so we just leave it on and merge the RFC with which it's associated.
• PSUnixFileStat: We haven't seen any reports of negative behavior, and it seems to be working well for those of us who use it.

Experimental (for now)

• PSCommandNotFoundSuggestion: Suggestions are still broken in non-pwsh hosts
• PSCultureInvariantReplaceOperator: Weirdly, our telemetry shows that this went down in 7.1, but we're not sure why, and there haven't been any issues filed on it since it was merged. @iSazonov it looks like you were the one to implement this, has this been useful for you and/or have you experienced or heard of any unintended behaviors?
• PSImplicitRemotingBatching: I recalled that this was somewhat incomplete, but we couldn't remember why. @PaulHigin can you weigh in here?
• PSDesiredStateConfiguration.InvokeDscResource: This is still not well fleshed-out, and additional DSC behavior like #13359 will be behind experimental in 7.1 as well, so there's little benefit to moving this out of experimental.
• PSNotApplyErrorActionToStderr: A fix for #3996 and #10512, namely that we're consistent in not treating output in stderr as errors that trigger ErrorAction, and including a fix to set $? correctly in cases where ErrorAction is no longer triggered.
• PSNativePSPathResolution: Some edge cases don't work as expected, so we decided to leave this as experimental until they're fixed.
• Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace: Some problems have been raised since we originally decided to move this to supported, so it will remain experimental in 7.1.

On their way (and will remain experimental)

• PSSubsystemPluginModel: This is the plugin model for minimal PS and PSReadline suggestion fixes. This feature will guard Get-Subsystem, and will also serve as a notation that the APIs are experimental and subject to change. (Still need to investigate how to notate that these are experimental)

[PaulHigin]

It has been a while since I thought about PSImplicitRemotingBatching. I remember that it is incomplete and not ready for prime time. There were some difficult scenarios that some users requested, but I haven't done any work on it.

It is an interesting idea, but I remember my feeling was that it is too limited in its current form, but probably not worth the effort of continuing since few people would use it.

[vexx32]

IMO to make the PSNullConditionalOperators feature more usable, we should disable ? as a valid variable name token by default, so that we can write things like $myObject?.Method() without the awkward ${myobject}?.Method() syntax.

True, it would probably be better off as a separate experimental feature (even if after the null conditional one is accepted as stable in itself), but IMO that form of the null conditional syntax is not especially usable because of that and I tend not to use it as a result of that.

[ALIENQuake]

Regarding PSNullConditionalOperators couldn't agree more with vexx32. This is the neat feature but the implementation makes it impossible to use. The 'question mark' char has no meaningful value by being a part of the variable itself.

[ThomasNieto]

I also agree with @vexx32. I've talked with multiple PowerShell scriptwriters at my company. They won't be using this feature due to the extra syntax required.

Not to rehash the entire conversation with disallowing the question mark in a variable names but if we had a small breaking change to force users that want question marks in their variable names to use the ${name?}?.Property syntax while allowing the vast majority to make use of null conditional operators using the familiar syntax $name?.Property.

[joeyaiello]

Updating the above list to:

• include PSNotApplyErrorActionToStderr name
• finalize the list
• change "Stable" to "Supported / Non-Experimental" to be more clear

[DHowett]

For PSNativePSPathResolution, https://github.com/PowerShell/PowerShell/issues/13638

[sdwheeler]

@joeyaiello Need a final list of what made it in and what didn't so we can update the docs. See https://docs.microsoft.com/powershell/scripting/learn/experimental-features for current doc.

[joeyaiello]

Made some edits above to reflect that a couple more features were brought back to experimental

• PSNativePSPathResolution
• Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace