We have many customers that run in disconnected environments and thus do mirroring, and we've been encouraging customers to move to the `oc-mirror` plugin as best way to do that.  However, we just became aware of a situation where our release-to-channel strategy and `oc-mirror` behavior is causing issues for customers that do selective mirroring of our packages (which seems to be a thing many of our customers want to do).
 
Briefly, our operator packages follow the pattern of having a channel per distinct feature release, eg. stable-2.2 for the 2.2.z releases, stable-2.3 for the 2.3.z releases etc.  We do this because our customers want to be able to choose  when they consume feature updates vs. only bug fixes.  We are probably also like a lot of Red hat operator packages not yet converted to submitting our bundle stuff into the publication pipeline in file-based-catalog format, rather counting on the conversation of the previous format via the tooling.
 
So here's the issue.  If we have a customer that is doing selective mirroring, say of the then-current most recent (and hence default) channel for our package, eg. with:
mirror:
platform: {}
operators:

• catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
  packages:
• name: multicluster-engine
  channels:
• name: stable-2.2
  additionalImages: []
  helm: {}
  then as soon as we publish the next release that introduces the stable-2.3 channel and makes it the default in the redhat-operators catalog (as seems best practice), a customer with an ImageSetConfiguraiton like the above is broken, and sees errors:
  The current default channel was not valid, so an attempt was made to automatically assign a new default channel, which has failed.
  The failure occurred because none of the remaining channels contain a "olm.channel" priority property, so it was not possible to establish a channel to use as the default channel.
  The customer can get around this by also mirroring the new (now default) channel, but our customers seem to want to avoid over-mirroring for time/space reasons I guess.

And while I'm sure we could avoid this issue if we were publishing using file-based-catalog format, converting to that is a big pill for us to swallow, especially since we don't really need any of the additional replacement-graph flexibility offered by that format.  We're happy with what we can get using CSV spec.replaces, olm.skipRange etc. to define our replacement graph, and happy that the catalog tooling aggregates that across our bundles as published.
 
It seems the current snags could be avoided if we only had a way in the ImageSetConfiguration to declare what the customer wants as the default channel, say with a new defaultChannel property like this:
<snip>
packages:

• name: multicluster-engine
  channels:
• name: stable-2.2
  defaultChannel: stable-2.2
  <snip>
  or maybe alternatively:
  <snip>
  packages:
• name: multicluster-engine
  channels:
• name: stable-2.2
  isDefault: true
  <snip>
  With this extension, the ImageSetConfiguration would not break when we publish the stable-2.3 channel, but continue to do exactly what it was configured to do until the customer decides they want the new channel's contents too.