Too complex; Don't need (TC;DN)

As soon as the MSI modules came to being, it was evident that it showed a different approach on the coding level - patterns like event sourcing and CQRS were embraced, but also, the functionality was offered in a very modular fashion. Very modular basically translates into having a lot of different modules, which could be a benefit if you know which modules to enable and which modules to disable.

And the moment of writing (Magento 2.4.6-p2) includes 73 modules. Theoretically, there would be a strategy behind which ones are needed in what kind of situation. For instance, in headless shops (PWA Studio anyone?), all of the modules ending with frontend-ui could be skipped. If you're not offering in store pickup, you would disable all those modules. Other scenarios would be: Not having bundled and/or configurable products, not using the Magento Admin Panel, not requiring low quantity notifications. Unfortunately, these scenarios are not documented and in practice, everyone seems to just either enable all inventory modules or disable all of them.

Even worse, the most common scenario that I have encountered in the field - just selling products via a single shop that only requires a single inventory source - is pretty hard to accomplish with MSI. And because of this, for this scenario, most people tend to disable all inventory modules or remove them via composer replacements. It is kind of awkward that a MSI project is meant to be so flexible, actually ends up to be removed because of this scenario not being covered well enough. (Because of this, I always stress the Multi in MSI: If you don't have multiple sources, most likely MSI is not for you.)

The legacy solution

When MSI is disabled or removed, we fall back to the original Magento_CatalogInventory. Which is deprecated. If you scan in the source code of the package magento/module-catalog-inventory for the word deprecated, you are greeting with numerous comments that tell you that it has been replaced with MSI. Except for that it is not a replacement. It is different functionality. MSI supports multiple sources and is overly complex for a single source. To stress this even more, if it is overly complex for a single source, it is not the right solution for single source shops.

Deprecation is just a marker. It doesn't do anything, if the thing that is being deprecated is actually never going to be removed. For instance, the Magento\Framework\Registry class is deprecated since ages, but still very wide-spread in both the core and third party extensions. Another example, if you build a triad of Model, ResourceModel and Collection, it requires you to depend on a deprecated mechanism, but the alternatives (CQRS, the Entity Manager) never were finalized.

Offering a choice on the composer level

I personally therefore favor that the deprecation is turned into a choice: If you want to manage your stock via a simple qty field per product, go ahead - there is nothing wrong with that. If you want to use MSI instead, go ahead. Because of this, I personally think that the Magento core, but also third party extensions should embrace this choice as well.

One way was something I built together with MultiSafepay almost three years ago: The payment gateway I helped develop was installed either via separate composer packages or by using a generic meta-package. The composer.json of the generic meta-package included a subpackage for the original inventory (multisafepay/magento2-catalog-inventory) or MSI (multisafepay/magento2-msi). If people didn't want to make a hassle, they could just use the meta-package. If people were picky, they could use the individual packages. This approach offered an approach.

Ideally, you would make a choice on the global level (your root composer.json for instance) to either use the MSI packages or use the original catalog inventory, but not both.

The problem of composer replacements

The composer replacement packages maintained by Yireo (()[]) allow to remove all MSI packages. Unfortunately, they don't allow to remove the multisafepay/magento2-catalog-inventory package (or other third party packages that depend on MSI) and this quickly leads into a mess. Likewise, if you would like to remove all MSI packages but keep all of the GraphQL packages, this could lead into troubles with the composer replacements, requiring you to move all replacements to your own root composer.json.

I hope to overcome this one day by adding a composer plugin to manage composer replacements automagically. But until that time (and only when that solution becomes so common ground that everyone benefits from this), a different approach is needed.

Prevent removal of the legacy inventory

Straight-forward I personally think that the legacy inventory should not be removed from the core. Or even better, the deprecation should be removed as well. Let's keep a simple solution like the catalog inventory that is working for so many.

Additionally, it would be really cool if third party extensions would embrace both inventory solutions using a composer switch like MultiSafepay did.