The operator uses a secret to store adminUser and adminPassword and exposes them to environment varibles (AMQ_USER and AMQ_PASSWORD) for configuring a broker's default admin user. The secret also stores CLUSTER_USER and CLUSTER_PASSWORD used to configure a cluster user used for broker cluster connections between broker pods.

The secret name follows the pattern <broker-cr-name>-credentials-secret

The operator allows a user to configure the adminUser and adminPassword in the broker CR, which the operator takes to inject the values into the secret.

Users also can provide their own secret of the same name with their own adminUser/adminPassword (also cluster_user and cluster_password) in it. In that case the operator will use the user provided values in that secret to configure broker. If the user also specifies adminUser/password in the CR, they will be used to replace the respective values in the secret.

In case user doesn't provide their own secret, one will be automatically created by the operator. Then the operator looks whether adminUser/adminPassword is explicitly specified in the CR or not. If any one is present in the CR, it will be added to the secret.
If not the operator uses a random value for it and added to the secret. (cluster user/password will be automatically generated always as they are not available in CR)

Since 7.10 the operator tracks the secrets by ownerReference - which means it only manage (create/update/remove) secrets whose ownerReferences refer to broker CR.
Only if a secret is created by the operator it will have such ownerReference.
that means the user provided secrets are no longer updated as the secrets don't have such ownership.

This introduces a incompatibility with older versions of operator which always updates the secrets with the values from CR (if present). Some may say it's regression.

Whether we need to fix it or not is up to discussion. But until a decision is made we need to document the current situation in our 7.10 release notes and let the users be aware of it.