We need to review the procedure on the migration to ClusterWide  mode, since the current on is incomplete, can lead to problems and it is not very well understandable. [1]

To start I think we should give a little bit better explanation of what discoverySelectors is about for customers to understand that this is mainly about how istiod will build its service registry from what the data it captures from the projects.

After that we should say that matchExpressions is optional and what we are providing is just an example and why. This field needs at least matchLabels or matchExpressions or a combination of both depending on the customer's environment. This should be explicit, because applying a similar configuration like this will lead to a huge amount of cluster projects (openshift-*) to be visible on the Mesh, which is not something desirable.
Another important thing is that we should mentioned that the discoverySelectors must include the smcp project, by either adding the label to the respective project or by adding matchExpressions like this:

  meshConfig:
    discoverySelectors:
    - matchLabels:
        istio-discovery: enabled
    - matchExpressions:
      - key: kubernetes.io/metadata.name
        operator: In
        values:
        - istio-system

Otherwise it will lead for the ingress and egress gateways that run on the smcp project to be out of the mesh and completely break the entire internal routing inside the Mesh, configured by the gateway and virtualservice CRs.

On the example for changing the ServiceMeshMemberRoll via the CLI [2], perhaps we can make an easier way, for example, for customer with a big number of members:

  1. Create a file with:

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
spec:
  memberSelectors:
  - matchLabels:
      istio-injection: enabled 
  
 2.  Create it by replacing the current one

 $ oc replace -f <smmr-yaml-file> --force 

 3. Apply the labels on the projects to be added as members.
 
With all that I think we should have a new section, giving a few examples how customers can simply add their projects to the new mode, something like:

 $ oc label ns/<my-project> istio-discovery=enabled
 $ oc label ns/<my-project> istio-injection=enabled

    

All current supported OCP versions
    

[1]https://docs.openshift.com/container-platform/4.15/service_mesh/v2x/ossm-deployment-models.html#ossm-excluding-namespaces-from-cluster-wide-mesh-console_ossm-deployment-models
[2] https://docs.openshift.com/container-platform/4.15/service_mesh/v2x/ossm-deployment-models.html#ossm-defining-namespace-receive-sidecar-injection-cluster-wide-mesh-cli_ossm-deployment-models