Any update on this at all? It's kind of desperately needed!

For me this is critically important as both of my clients use retention policies to secure content. Beyond this content retained by other policies such as labelling is likely to have the same effect - the sites cannot be easily archived and result in a manual process ultimately to go through the failed archives and re-archive the groups - doubling up on the retained archives as it is not possible currently to determine failed archives in the Azure blob storage, to those that were successful.

Coupled to this we have seen evidence where retention policies are applied inconsistently across two policies, resulting in the GROUP being deleted by the user decision to archive a Group connected site, but the SharePoint site remaining. This has happened I believe due to some kind of policy precedence - though I have no evidence to back this up - the result is I have over 400 sites that are now 'Ghosted' and I'm having to work with Microsoft to resolve this issue - which is rather problematic. So this is the scenario:

Policy A has a retention policy to protect SharePoint workloads
Policy B has a retention policy to protect SharePoint AND Groups workloads

What I believe is that due to one policy not retaining Groups, the SG:Apricot application has been able to delete the Group from working through the Policy A, but then blocked on the SharePoint workload protection for Policy A and Policy B. Again, I have no proof that this is happening other than the fact that I have had over 400 groups/sites that are exhibiting issues that their Group connection has been removed and is ghosted in the tenant. In fact, I am able reproduce this issue quite easily, but able to recover the group to correctly archive the group/site using SG:A.

How would I perceive this working in the future? Some kind of interaction with PowerAutomate with a notification to manually (or automatically) execute the exclusion of a site from all retention policies. I dont know if its possible to do this in conjunction with PowerAutomate, or just simply build the notification/approval process into the SG:A chat bot so that it 'Talks' to an SG:A Administrator Teams channel or something? The application should be able to detect that a retention policy is holding onto the Group, Teams AND SharePoint workloads before archiving, otherwise this application and it's ability for end user decisions to archive a Teams/Groups is pretty much redundant to us. To that point and due to the 400~ sites that are currently sitting in a ghosted state without the Groups available, we have turned off the user decisioning to archive sites. This is critically difficult for one of my clients where we are going through a storage remediation exercise and have less than 5Tb of space to play with that cannot be extended. So time is of the essence for us and we are having to manually manage this data and archive it where identified.

Many Thanks,
Jason.

Agree. Need to somehow integrate, or at least avoid conflict between Azure policies (retention, access reviews) and Sharegate policies

Ability to rely on the tenant's Retention policies for archiving, rather than on Azure (be it ShareGate's or our own). So basically a third option needs to be available.