I agree with how TIMOTHY_MANGAN phrased the requirement, and want to add that this is critical to my organization moving from App-V to MSIX. In our case, we use an XML editor which is designed to be customized. 20 years of customization are involved, such as .NET code, Perl code, and many other integrations. A lot more than what is normally considered a plug-in. The editor is a Win32 app which rarely changes, but the customization package changes often to meet requirements. To handle the deployment challenges, we package the customization package into App-V, and integrate it with the editor using RunVirtual. The editor is developed by a third-party and is not ready for MSIX. The only other option is to use a stub executable to start the virtual environment and launch the non-virtualized executable, but it is hard to enforce this. If the user adds the non-virtualized executable to the taskbar, then the next time they launch it the virtual environment will not start.
Having said all that, RunVirtual is not necessarily the ideal solution. It would be easier if the executable could be identified in the MSIX package, and automatically get applied when publishing. This flips Tim's other idea on its head, and allows a plug-in to modify a parent process, rather than a child process. Still, we've automated the RunVirtual modification in Powershell, and are happy enough with it, as long as we can use it with MSIX.