storage capacity: revise type visibility

Author: pohly

keps/sig-storage/1472-storage-capacity-tracking/README.md

@@ -844,19 +844,21 @@ enhancement:
   the enablement)?**
   Yes.
 
-  Registration of the `CSIStorageCapacity` type is controlled by the feature
-  gate, so when disabling support in the API server, the new object type
-  will disappear together with the new flag in
-  `CSIDriver`, which will then cause kube-scheduler to revert to
-  provisioning without capacity information. However, the new objects
-  will still remain in the etcd database, they just won't be visible.
-
-  When disabling it in the scheduler, provisioning directly reverts
-  to the previous behavior.
-
-  External-provisioner will be unable to update objects: this needs to
-  be treated with exponential backoff just like other communication
-  issues with the API server.
+  In Kubernetes 1.19 and 1.20, registration of the
+  `CSIStorageCapacity` type was controlled by the feature gate. In
+  1.21, the type will always be enabled in the v1beta1 API
+  group. Depending on the combination of Kubernetes release and
+  feature gate, the type will be disabled. However, any existing
+  objects will still remain in the etcd database, they just won't be
+  visible.
+
+  When the type is disabled, external-provisioner will be unable to update
+  objects: this needs to be treated with exponential backoff just like other
+  communication issues with the API server.
+
+  The new flag in `CSIDriver` will always be removed when disabling the
+  feature gate or when rolling back to a release older than 1.19. In that
+  case kube-scheduler will revert to provisioning without capacity information.
 
 * **What happens if we reenable the feature if it was previously rolled back?**