Not necessarily a TechPreviewNoUpgrade blocker, but today ClusterImagePolicy status has slots for conditions, but nothing populating them since OCPNODE-2336 dropped the scope guard. This ticket is raising qiwan233's:

If both MC for GPG and ClusterImagePolicy exist, MachineConfig for GPG and 99-worker/master-generated-registries(MachineConfig for ClusterImagePolicy), the MC has higher alphanumeric order will win.

to get some UX discussion. I'm not all that familiar with what goes on inside the MCO, but ClusterImagePolicy is one (of several?) resources feeding 99-...generated-registries MachineConfigs, which in turn feed rendered... MachineConfigs which MachineConfigPools roll out to nodes. There's a bit of a hint in the MachineConfigPool about what went in:

$ oc get -o json machineconfigpool master | jq .status.configuration
{
  "name": "rendered-master-dc3b183de18381590753f5d613cf1997",
  "source": [
    {
      "apiVersion": "machineconfiguration.openshift.io/v1",
      "kind": "MachineConfig",
      "name": "00-master"
    },
...
    {
      "apiVersion": "machineconfiguration.openshift.io/v1",
      "kind": "MachineConfig",
      "name": "99-master-generated-registries"
    },
    {
      "apiVersion": "machineconfiguration.openshift.io/v1",
      "kind": "MachineConfig",
      "name": "99-master-ssh"
    }
  ]
}

But nothing I can see that pins a particular revision of 99-master-generated-registries there, or anything that maps 99-master-generated-registries MachineConfig back to the (Cluster)ImagePolicies and other resources that feed it. Is there anything we can do to make this easier to track, so we can signal when a (Cluster)ImagePolicy is not being pushed out to a given MachineConfigPool?