I am grateful to see the response to the previous query looking for guidance on implementing Extensions in the AppXManifest, namely Extensions in the package manifest schema - Windows UWP applications | Microsoft Docs.
The concept of separation of app specific extensions versus package-level (applying to all apps in the package) might need a bit of tweaking, and thus tweaking of the supported element lists in that documentation.
While multi-application packages are one reason for package level extensions, another is package extensions that are (or could be) unrelated to a specific application. A key example would be in-process com extensions that are intended for applications outside of the package. Currently all com extensions must be placed under an Applications/Extension, and there is support for in-process COM dlls to be added as a Surrogate in the manifest, at least from a validation standpoint but they don't work. Shell Extensions are an example of this, where the explorer.exe process should integrate them
into the explorer process, but publishing in-process shell extensions for consumption by other application level processes not in the package has been traditionally supported.
So I believe the list of package level extensions should be extended, starting with the shell extensions. However, it is possible that Microsoft wants to support the concept of shell extensions without adding them directly into the explorer.exe process (for security issues). Which is OK, as long as we can get support for traditional shell extensions. In computing, it is really all about the data and end-users don't always start with the app, but the data file. Integrated shell commands are not enough, and shell extensions have been a long-standing solution. While some shell extensions have been migrated to independent Manifest elements for support, most have not. I believe Microsoft has some work to do here, and a roadmap (even without dates and just saying this is in or out of scope) will be helpful to developers WANTING to move their existing applications to MSIX.