Let's be more specific. The Microsoft MSIX Packaging Tool.
This package is a MSIX package that at runtime generates a configuration file that is placed under the user profile LocalState folder. This configuration file contains both exclusion settings and certificate data used while running the tool. A larger organization will want to standardize on a single exclusion list and certificate and have each packager using the same setup.
So a modification package that contained just the settings.xml file might seem ideal. But, as far as I know, Modification packages may only override existing package files using the VFS path to the native equivalent path that the app will request. So I don't see how to generate a modification package for this purpose.
If Software Vendors do start distributing in MSIX form, we will start seeing this scenario a lot. We loose one of the key benefits of MSIX packages if Modification packages cannot be used.
I strongly agree that this is a show-stopper. PSF launch scripts would be eventually handy, but the problem is they are tied to an entry point via an application entry, and modification packages sadly do not override nor add applications... Even if the original app already uses PSF, its config.json is not in VFS path, which means that overriding the original setup is not possible. Other solutions (like overriding executable entry point with a custom wrapper that ensures the data is initialized in a proper way) are way too "hacky", and also work only if the app installs itself to VFS. And re-packaging the original app with a new identity just to bring the required settings kills the update chain and the whole idea of separation of apps from their add-ons/modifications.