It would be counter-intuitive for uninstalling a package from one prefix to affect all other prefixes. I suppose registering features and components probably wouldn't do any harm, but they don't help us either. If we need to uninstall a shared package, we need to be able to do the uninstall in any prefix, not just the one that installed it.
Ideally, we shouldn't need the original msi (which contains the cab file and therefore an extra copy of most of the files) to remove the shared files. If there's a way to save just the installation database and use that, we could do that, but that depends on whether the uninstall process depends on the features and components having already been registered within the same prefix.
I really don't think prefix reference-counting is viable for reasons I've already explained.
Anyway, here's a possible design:
User-local addon installs will be extracted to: ~/.local/share/wine/addons/hash-of-wine-path/addon-arch/version
We will assume that each install of Wine will require only one version of each addon for each architecture. We can also assume that if the Wine version changes (which changes the addon version requirement), the prefix will have to be updated. So if we find a version of an addon that we don't need, we can safely delete it. To handle z: deletion, on prefix update we could make a symlink from a fixed location in c: to the specific addon path for the current Wine install.
When we need to download an addon from the Wine website, appwiz will download the msi file to a temporary location. It will create a temporary folder in the addon-arch directory and install the msi with SHAREDINSTALLDIR set to that location. The msi will just install the files and not register itself when that property is set. If the install succeeds, appwiz will rename that directory to the version number (which may fail if another prefix did the same thing, that's ok). Then the msi can be deleted so we're not duplicating the contents, along with any obsolete versions.
For most users, there will be only one wine install. If there are multiple installs, we may duplicate some files. I think that's OK. Developers are likely to have a separate "source tree" and "installed" version of Wine. We can help with that case by making the build system able to download and install the pre-built addons if configured to do so.
Then once we've done all that, we notice that we're using msi only as an archive format and abandon it in favor of cab or something.