Update future feature flags default table

This commit updates the table of new feature flags and their default
values at each stability level.

teps/0138-decouple-api-and-feature-versioning.md

@@ -166,11 +166,11 @@ See [implementation plan](#implementation-plan) for more details on the PerFeatu
 
 All **new** features can only be enabled via per-feature flags. When they first get introduced as `alpha`, they will be disabled by default. When new features get promoted to `stable`, they will be enabled by default according to the following table:
 
-| Feature stability level | Default                     |
-|-------------------------|-----------------------------|
-| Stable                  | Enabled; Cannot be disabled |
-| Beta                    | Disabled                    |
-| Alpha                   | Disabled                    |
+| Feature stability level | Default  |
+| ----------------------- | -------- |
+| Stable                  | Enabled; Cannot be disabled once the flag is removed (after deprecation)  |
+| Beta                    | Disabled |
+| Alpha                   | Disabled |
 
 Note that per-feature flags that have stabilized cannot be disabled. We will deprecate the per-feature flag after it has become stable and then remove it eventually after the deprecation period according to the API compatibility policy. We will give deprecation and later removel notice of the per-feature flags via release notes after their promotion to `stable`. Cluster operators who do not want such opt-in features would have enough notice to implement admission controllers on their own to disable the feature.
 For example, when a new future feature `pipeline-in-pipeline` becomes stable in v0.55, it would be enabled by default and cannot be disabled after the release. We would need to include in the release note of v0.55 that we are enabling the `pipeline-in-pipeline` feature by default and deprecating its feature flag. And after the deprecation period, we would remove the feature flag.