minor updates to alternate proposals based on feedback

Author: KirkMunro

1-Draft/RFCNNNN-Optional-Features.md

@@ -78,10 +78,19 @@ Get-OptionalFeature
 
 # Output:
 #
-# Name                              EnabledIn Source                              Description
-# ----                                ------- ------                              -----------
-# OptionalFeature1                   Manifest PSEngine                            Description of optional feature 1
-# OptionalFeature2                    Session PSEngine                            Description of optional feature 2
+#     EnabledIn: Script
+#
+# Name                              Source                              Description
+# ----                              ------                              -----------
+# OptionalFeature1                  PSEngine                            Description of optional feature 1
+# OptionalFeature2                  PSEngine                            Description of optional feature 2
+#
+#
+#     EnabledIn: NotEnabled
+#
+# Name                              Source                              Description
+# ----                              ------                              -----------
+# OptionalFeature3                  PSEngine                            Description of optional feature 3
 
 # Enable an optional feature by default in PowerShell
 Enable-OptionalFeature -Name OptionalFeature1
@@ -128,7 +137,15 @@ This new parameter would enable optional features in the current script file.
 Get-OptionalFeature [[-Name] <string[]>] [<CommonParameters>]
 ```
 
-This command would return the optional features that are available in PowerShell. The default output format would be of type table with the properties `Name`, `Enabled`, `Source`, and `Description`. All of those properties would be of type string except for `Enabled`, which would be an enumeration with the possible values of `NotEnabled`, `Session`, `Manifest`, and `Script`. This differs from experimental features where `Enabled` is a boolean value. Given the locations in which an optional feature can be enabled, it would be more informative to identify where it is enabled than simply showing `$true` or `$false`.
+This command would return the optional features that are available in PowerShell. The default output format would be of type table with the properties `Name`, `Source`, and `Description`, and with the results grouped by the value of the `EnableIn` property. All of those properties would be of type string except for `EnabledIn`, which would be an enumeration with the possible values of `NotEnabled`, `Session`, `Manifest`, `Script`, and `Scope`. This differs from experimental features where `Enabled` is a boolean value. Given the locations in which an optional feature can be enabled, it would be more informative to identify where it is enabled than simply showing `$true` or `$false`. The enumeration values have the following meaning:
+
+|Value|Description|How to set the feature up this way|
+|--|--|--|
+|NotEnabled|The optional feature is not enabled at all|Disable-OptionalFeature command|
+|Session|The optional feature is enabled by default in all PowerShell sessions|Enable-OptionalFeature command|
+|Manifest|The optional feature is enabled in the manifest for the current module|OptionalFeatures entry in module manifest|
+|Script|The optional feature is enabled in the current script|#requires entry in script file|
+|Scope|The optional feature is enabled the current scope|Use-OptionalFeature command|
 
 ### New command: Enable-OptionalFeature
 
@@ -163,3 +180,7 @@ Experimental features and optional features are very similar to one another, so
 ### Supporting a `-Scope` parameter like the experimental feature cmdlets do
 
 The `Enable-OptionalFeature` and `Disable-OptionalFeature` cmdlets could support a `-Scope` parameter like their experimental feature cmdlet counterparts do. I felt it was better to remove this for optional features, because it may be risky to allow a command to enable an optional feature in a scope above the one in which it is invoked, influencing behaviour elsewhere.
+
+### Allow optional features to be disabled at a certain level
+
+Certain optional features may be so important that PowerShell should be installed with them to be on by default. In cases where this happens, scripters should be able to indicate that they want the opposite behaviour in a script file or module, so that they can ensure any compatibility issues are addressed before the feature is enabled in that module/script. With this in mind, we could either allow optional features to be disabled at a certain level, or stick with enable only, inversing how the optional feature is designed such that turning it on effectively disables a breaking fix that was deemed important enough to have fixed by default.

1-Draft/RFCNNNN-Propagate-Execution-Preferences-Beyond-Module-Scope.md

@@ -128,6 +128,8 @@ As per the optional feature specification, the optional feature can be enabled i
 
 [Some members of the community](https://github.com/PowerShell/PowerShell/issues/6745#issuecomment-499740080) feel it would better to break compatibility here. On the plus side, not having to deal with this an an optional parameter would be ideal; however, to increase adoption of PowerShell 7, it would be better to make the transition from PowerShell 5.1 into 7 easier by having as few breaking changes as possible.
 
+One way to achieve this while supporting users who don't want the breaking change would be to inverse the optional feature, where the breaking change is in place and users opt out of the breaking change instead of opting into it. Another way would be to change the optional feature design such that users can turn them off in scripts/modules if those scripts/modules are not ready to use the breaking change. See the alternate proposals and considerations section of RFCNNNN-Optional-Features for more information.
+
 ### Support `-DebugAction`, `-VerboseAction`, and `-ProgressAction` if those common parameters are added
 
 RFCNNNN-ScriptBlock-Action-Preference suggests that we consider adding `-DebugAction`, `-VerboseAction`, and `-ProgressAction` common parameters. These are important to consider adding, because beyond the `-Debug` and `-Verbose` switch common parameters (which only support `ActionPreference.Continue`), the new common parameters would be the only way to propagate execution preferences for debug, verbose, and progress messages to all commands that are invoked. See RFCNNNN-ScriptBlock-Action-Preference for more details.