In fairness, MSIX is very different to MSI and ClickOnce was primarily a way to bootstrap MSIs from the web.
MSI (long since deprecated) is essentially an ad-hoc relational database serialized to a file with embedded blobs that tells a generic engine how to install files and update the registry. It was written for Office in the 90s and was therefore dominated by the retail model of physically shipping CDs.
MSIX is a totally different beast. It's more like a package for Linux. The format is a signed zip file with some embedded XML files. One of them is a "block map", which is basically an index into the zip data by chunk hash. Packages are installed to immutable directories, which lets Windows optimize out the download of data it already has on disk by copying from other packages or even just hard linking files together. Delta updates thus come for free (albeit not as powerful as diff based schemes when inserting data into the middle of a file). Another XML file declares how the app should be integrated into the OS. The old MSI/EXE model of manually patching and unpatching the registry and filesystem to do integration is gone here; for example, if you want to register a CLI command then that's an XML tag, if you want a file association or URL handler, that's a bit more XML. Windows takes care of wiring everything up and removing it on uninstall.
Most importantly, MSIX takes care of online updates. MSI never did this. You can register a URL for a package that points to yet another XML file, and Windows will download deltas and apply them in the background even if the app isn't running (a la Chrome).
So Microsoft's packaging tech hasn't churned that much. There were CABs from the Win3.1 days, then later MSI from the late 90s, and starting in Windows 10-ish timeframe MSIX. All of these are very different technologies.
One of the nice things about MSIX is that it's feasible to create them from other platforms, because although Microsoft's tools are Windows specific the format is simple enough to reimplement. Not simple - the way they compute the block map and signature data effectively requires you to write your own ZIP library to create them - but it can be done and that's why the new Conveyor tool [1] is able to create Windows self-updating desktop apps from Linux and macOS. If you have a pre-compiled runtime like Electron or the JVM then you can push out updates with one command from your Mac/Linux dev laptop, it's no harder than publishing a static website by rendering Markdown to HTML, and that makes it feasible to develop quick lightweight desktop apps in a convenient manner. With the old MSI or InstallShield tech it would have been much harder to create a cross platform tool like Conveyor.
[1] https://hydraulic.software/ (it can also do Linux and macOS apps from Windows, but those are a bit easier)
In my experience MSIX is the typical MS Windows project where it sounds really cool and looks well documented and supported until you actually try to use it. If you're on the beaten path, like a mobile app port for the windows store, it's probably fine. But if you're trying to do anything out of the ordinary you have to start doing Microsoft archaeology to figure out why something doesn't work.
For example certain build configurations would cause the runtime runtime to be somehow slightly different from the build runtime and it would trigger control flow integrity to immediately kill the app on startup which was very difficult to debug.
Also from documentation it looks like it's possible to install a background service and communicate with it over a named pipe from another application in the same package but in practice I don't think it's actually possible, even in a full trust app.
I think the goals of MSIX and the App SDK are good and I applaud them trying to make it flexible to support every kind of app, it just hasn't had the time or resources put in to be really worthwhile over just using NSIS at present.
Problems with CFI aren't related to the packaging mechanism though. Mismatches between DLLs have been an issue with Windows for a long time and the solution is usually to bundle the versions you need. Not sure about the background service thing, we haven't tried that.
I'd say that Windows in general is disappointingly buggy but it's been that way for a very long time, I remember having to work around bad Windows bugs in the 95 and XP days too. It just comes with the territory. We use MSIX as raw material and either work around bugs or reimplement features as necessary. The results seem to work fairly well. MSIX also has the advantage of being maintained and general purpose, which sounds basic, but a fair number of the competitors aren't.
Is it really deprecated? Isn't MSI still the only installer type directly supported by Group Policy? My company had an enterprise customer request an MSI for that reason.
MSIX is interesting but effectively unusable outside the Store (I spent a few months of my life trying to do that at $PREVIOUS_JOB). Installation will fail on a high percentage of machines, and you'll mostly be out of luck. There's a reason nobody at Microsoft uses it for installation outside the Store (Office did for a while but they gave up).
There are some bad bugs in older Windows versions, but we were always able to diagnose and work around them. It's part of the value Conveyor provides. We have it working now and the results are pretty good: fast installs and uninstalls (as long as there isn't a lot of latency to the web server), especially if you already have the files locally, background or check-on-start updates, management from the CLI, group policy, MSIX Hero and so on.
The alternatives are also not that great. I looked at many. Some are buggy, some are abandoned, some require complex server-side logic etc. The situation on Windows is far from ideal; it speaks to the general neglect of the platform. Nonetheless with a tool that works around or 'polyfills' issues MSIX can work well.
I think it's driven by a desire for strict validation. They provide XSD schemas and use them internally. Conveyor uses them too which not only helps catch internal bugs, it means if you provide a snippet of XML to do OS integrations the tool doesn't support yet then you still get good error messages at package build time telling you what you did wrong.
There are similar schema languages for JSON these days, but without any equivalent to namespaces. Microsoft uses versioned namespaces heavily in the AppX Manifest. It's got a bit crazy, a typical manifest might have 10 different xmlns declarations, but it means that if you mis-name an element or (more likely) put it in the wrong place that won't be silently ignored, it'll trigger a validation error. To get that you need to able to assign each element to a specific fixed schema and then compose them. If you just have a single schema and evolve it without any concept of namespaces, old software can't tell the difference between a mistake and a new extension from the future.
Microsoft don't have any generically extensible binary format that they use consistently, like Google does with protobufs. Besides, XML isn't so bad.
Look at the alternative: Apple went with a generic binary config format for macOS (binary plists) but then introduced an XML version anyway. As an industry we've never got any good at managing the dichotomy between efficient-for-machines binary formats and efficient-for-humans text formats.
MSI (long since deprecated) is essentially an ad-hoc relational database serialized to a file with embedded blobs that tells a generic engine how to install files and update the registry. It was written for Office in the 90s and was therefore dominated by the retail model of physically shipping CDs.
MSIX is a totally different beast. It's more like a package for Linux. The format is a signed zip file with some embedded XML files. One of them is a "block map", which is basically an index into the zip data by chunk hash. Packages are installed to immutable directories, which lets Windows optimize out the download of data it already has on disk by copying from other packages or even just hard linking files together. Delta updates thus come for free (albeit not as powerful as diff based schemes when inserting data into the middle of a file). Another XML file declares how the app should be integrated into the OS. The old MSI/EXE model of manually patching and unpatching the registry and filesystem to do integration is gone here; for example, if you want to register a CLI command then that's an XML tag, if you want a file association or URL handler, that's a bit more XML. Windows takes care of wiring everything up and removing it on uninstall.
Most importantly, MSIX takes care of online updates. MSI never did this. You can register a URL for a package that points to yet another XML file, and Windows will download deltas and apply them in the background even if the app isn't running (a la Chrome).
So Microsoft's packaging tech hasn't churned that much. There were CABs from the Win3.1 days, then later MSI from the late 90s, and starting in Windows 10-ish timeframe MSIX. All of these are very different technologies.
One of the nice things about MSIX is that it's feasible to create them from other platforms, because although Microsoft's tools are Windows specific the format is simple enough to reimplement. Not simple - the way they compute the block map and signature data effectively requires you to write your own ZIP library to create them - but it can be done and that's why the new Conveyor tool [1] is able to create Windows self-updating desktop apps from Linux and macOS. If you have a pre-compiled runtime like Electron or the JVM then you can push out updates with one command from your Mac/Linux dev laptop, it's no harder than publishing a static website by rendering Markdown to HTML, and that makes it feasible to develop quick lightweight desktop apps in a convenient manner. With the old MSI or InstallShield tech it would have been much harder to create a cross platform tool like Conveyor.
[1] https://hydraulic.software/ (it can also do Linux and macOS apps from Windows, but those are a bit easier)