currently,the MCO merges Machine Configs in alphanumerical order. This means the earlier alphabetical MCs are always the parent while the later ones are the children. The way our merging works here:

https://github.com/openshift/machine-config-operator/blob/5843b7a4b27f15bc3313ce8a41ef6de792081fcb/pkg/controller/common/helpers.go#L98-L103

leads to a process where configs like "worker" are always processed and therefore merged last. In a situation where a custom config has files with the same name but different contents as worker, that custom data is lost.

The priority will still be determined via alphanumerical means however, when we are merging, we will consider a new priority order.

This priority order will be established via an annotation. This results in scenarios where users can fix the issue on their own when running into it rather than renaming the configs to later alphanumerical sequences.

This will allow us to pick and choose config entities we want, even opening the door for a user choice as to which behavior they want. Changing this behavior will produce a more expected workflow since most customers believe custom pools have a higher precedence than worker pools/nodes.