There is no specific intent on this. The only constraint is today in PM we cannot create a custom topology other what it provides out of the box. The only other way of getting this custom topology is to construct this using the exiting policy.
As I said earlier you can have
DatasetA created using DR Mirror Protection Policy for the primary.
DatasetB created using Backup Then Mirror Protection Policy for the same primary.
DatasetA created using DR Mirror and Backup Protection Policy for the primary.
Dataset B created using Mirror policy from the SnapVault destination.
Is the design intent of two separate policies to decouple the DR policy from any backups?
Can you elaborate on what you mean by any backups ? I am not quite clear on this.
Does this enable a specific behavior that I should show my customer?
There in no difference I can see, as irrespective of how we build the topology we would still have a VSM base and SV base snapshot on the primary.'
Data ONTAP introduced a option in version 7.2.4 and later called cf.takeover.change_fsid which by default is ON. This causes FS ID of volume to change when failover or give back happens( like Metro Cluster).
If a volume which is a part of Metro Cluster is also being backed up using Protection Manger in a Dataset, since DFM/PM tracks the uniqueness of a volume using FS ID, the dataset resource are removed during a cluster takeover or give back due to the option being turned ON by default.
The culprit is the option cf.takeover.change_fsid. being turned ON. This options only affect volume which are just part of Metro Cluster and not Just any HA controller.
Its suggested that volume from the controller like Metro Cluster are recommend not be added to a dataset, if this option is turned ON.