Description of problem:

From [1]:

  $ oc adm release extract --to manifests quay.io/openshift-release-dev/ocp-release:4.6.0-fc.6-x86_64
  Extracted release payload from digest sha256:933f3d6f61ddec9f3b88a0932b47c438d7dfc15ff1873ab176284b66c9cff76e created at 2020-09-14T21:50:05Z
  $ diff -u0 <(yaml2json <manifests/0000_50_cluster-storage-operator_01_operator_namespace.yaml | jq -S .) <(yaml2json <manifests/0000_50_cluster-csi-snapshot-controller-operator_00_namespace.yaml | jq -S .)
  --- /dev/fd/63	2020-09-15 21:57:52.836562697 -0700
  +++ /dev/fd/62	2020-09-15 21:57:52.837562709 -0700
  @@ -7,0 +8,3 @@
  +    "labels": {
  +      "openshift.io/cluster-monitoring": "true"
  +    },

Ideally, we'd either have a single manifest or [2,3] would match.  Seems like the divergent overlap is from [4], which went out with 4.5.1 [5] and was backported to 4.4 [6].  Diverging by label isn't terrible, because the CVO merges labels [7,8] and only attempts to stomp the in-cluster object if the in-cluster object diverges in a manifest-specified key [9].  But would be nice to remove the risk of more serious divergence.

Based on the manifest runlevel docs [10,11,12] (we need to cleanup and unify that a bit on the CVO side), you could have a single manifest that was installed before either operator on update if you moved it to runlevel 49 as 0000_49_cluster-storage-operator_01_operator_namespace.yaml or some such.  Or you could leave the overlapping manifests, update one to remove any divergence, and punt unification into a single manifest to some future work if/when you ever need to make a change to the manifest that would temp the CVO into stomping back and forth on itself.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1879184#c2
[2]: https://github.com/openshift/cluster-storage-operator/blob/dd5f84fa86e68133d3295239ff426dd59f24039d/manifests/01_operator_namespace.yaml
[3]: https://github.com/openshift/cluster-csi-snapshot-controller-operator/blob/65d4ecf55c44572e5c57ea685869506bce0bd4fe/manifests/00_namespace.yaml
[4]: https://github.com/openshift/cluster-csi-snapshot-controller-operator/pull/34
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1815552#c11
[6]: https://bugzilla.redhat.com/show_bug.cgi?id=1816826
[7]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/lib/resourceapply/core.go#L32
[8]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/lib/resourcemerge/meta.go#L13
[9]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/lib/resourcemerge/meta.go#L37
[10]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/docs/dev/operators.md#what-is-the-order-that-resources-get-createdupdated-in
[11]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/docs/user/reconciliation.md#manifest-graph
[12]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/docs/dev/upgrades.md#generalized-ordering