Today's logic with iGroup is way too strict and creates an unwanted situation. As documented in the following KB: VSC and VASA_Provider/Why does Virtual Storage Console (VSC) create "rcu_generated_alua" iGroup and Storage Replication Adapter: What determines if a new initiator group or export policy is created during a failover operation? , we learn a new iGroup gets created if the system doesn't find an equivalent iGroup with all initiators. So far, nothing's wrong but the problem appears when you have an iGroup with all detected initiators but with extra initiators used by your backup system whose requirement is to connect on a LUN to backup or restore. Your only way to back to your original IGroup is to "force" unmap, map the LUN again and rediscover your system storage. It creates a system service disturbance which is a situation no one wants.
Now, you add your extra initiators to an automatically created iGroup by either VSC or SRM well next time you do a similar operation like creating a LUN/NFS or failOver, it will try to create a new iGroup or choose an iGroup with exact same list of initiators/export.
Would it be possible to switch or leave the operator to decide to use minimal requirements (detected initiators) instead of strict requirements?