Having  chatted to Pure Storage, I got

 PG = Protection Group; SM = Safemode;

Commvault uses vol snaps for most operations. PGs come in when customers use async replication or explicitly enable PGs in the CV config. (CV also called out PGs for Oracle archivelog snaps; I haven't tested this myself to be sure whether it always uses them or only in those two cases.) CV creates its own PGs per subclient (data set) and cannot enable SM on them (until they are on APIv2--this was the "first" I mentioned)--but customers can enable SM manually. Dynamic detection means they will adjust the PG members based on where the data sits when the backup job runs. VMs moving due to Storage vMotion, adding or consolidating vols in a DB, etc. will trigger CV to change the PG membership. If this includes removing a vol, and SM is turned on for the PG, the job will fail and continue to fail until Pure support can remove the vol.Auto-on is a separate consideration. There's no opt-out for CV without APIv2. Any temp vols they create will go in the default PG. CV will still destroy and eradicate them. If they exist when the default schedule hits, they will be snapped in the default PG, so auto-on will most likely affect capacity (but not for sure and impossible to accurately predict how much).So, to recap:

• If customers want SM but not on CV's snaps, they can safely use PG-level SM with PGs they create. CV will happily coexist with that.
• If they want SM on CV's snaps, they either need to use array-wide or force CV to use PGs, then manually enable SM on CV's PGs.
• There are a couple of cases like Oracle archivelogs where we expect CV to remove vols from PGs regularly, which will fail if SM is enabled--regardless of array-wide or PG-level.
• Auto-on doesn't affect any of these other behaviors, but it is likely to pick up at least some of CV's temp volumes and use some extra capacity.

So I am trying to understand the configuration change to enable commvault to default to use Protection  Groups for snapshot operations