WiX 7: supported way to associate MSI and related-bundle work with one Burn Apply?

[InsuranceTSMCC]

Question

I am evaluating a native out-of-process BA with WiX 7.0.0 for a per-machine Windows desktop application. I want stock Burn and Windows Installer to retain responsibility for servicing and rollback.

The goal is to keep the application from reopening until the whole bundle maintenance operation and its recovery have settled, rather than releasing a guard between individual packages.

The operation needs to cover:

• Normal MSI execution and any compensating package execution during Burn rollback.
• Removal of an older MSI by RemoveExistingProducts, scheduled after InstallInitialize.
• Related-bundle removal and restoration during failed-upgrade recovery.

The MSIs are intended to be serviced through the bundle. A custom action or related BA should be able to distinguish participation in the current bundle operation from an independently launched MSI or another setup instance. This is not intended to protect against a malicious machine administrator, and it must not prevent Windows Installer's own scripted rollback.

What is the supported WiX pattern for associating those participants with the exact active Apply operation?

I have reviewed the out-of-process BA guidance and the public OnExecutePackageBegin, OnExecuteMsiMessage and SendEmbeddedError interfaces. I have not found an explicit operation-membership or executing-peer identity contract there. I do not want to assume a package label, declared PID, or MSI property is sufficient authorization.

Is there a documented trust guarantee for the forwarded callbacks, or a supported way to carry and validate operation-specific context through both RemoveExistingProducts and related-bundle recovery? If that is not a supported boundary, what standard approach would you recommend for the whole-operation application guard?

I would like to avoid private Burn arguments/handles, an engine fork, or replacing stock servicing. A documentation or example pointer would be appreciated. This is a design/usage question, not a report of a demonstrated WiX vulnerability.

Thank you.

Open Source Maintenance Fee

• I (or an organization I'm a member of) pay the Open Source Maintenance Fee by sponsoring the wixtoolset project because I support the maintainers.

[InsuranceTSMCC]

We are also considering an approach where each MSI enforces its own safety, without requiring custom setup-session credentials. What supported pattern keeps the application closed throughout multi-package maintenance and rollback, restores usability after successful rollback, and safely handles interrupted servicing? A short-lived privileged coordinator is acceptable; stock Burn/MSI should retain responsibility for installation and recovery.