Technical Design. Open Questions

1. Synchronization of Legacy stock systems with MSI (bi-directional synchronization). Problem: In the legacy system "in_stock" field of StockItem is a partially calculatable field as it takes into account "is manage stock" configuration option, in MSI - "in_stock" field of SourceItem - not calculatable, but specified by admin. This sometimes lead for incorrect "Is In Stock" status for products. The issue is particularly described here - https://github.com/magento/inventory/wiki/%5BDRAFT%5D-Synchronization-between-legacy-inventory-data-and-MSI
2. Modularity. Currently, we segregate business logic by API, Implementation, AdminUi modules. Modules containing implementation and modules containing UI should communicate to each other via API modules only. Problem: we need to introduce "sugar API" which wrap existing API. Thus, implementation of one ServiceContract refers to other services. This introduces two issues:
   • Replaceability. Substituting implementation of one API not guarantee that API being called in old implementation would be called by the new implementation, so there is no guarantee that plugins assigned to API would be called.
   • To prevent business code from excessive logic "sugar APIs" appear. Which just wrap existing fine-grained API. Like, getFirstName / getLastName combined into getFullName for Customer object. Thus, as a result, we end up with several APIs which could be used for achieving the same business operation. More than one pluginization points.
3. Remove setter methods from Entity Data interfaces in Service Contracts. After this PR would be merged https://github.com/magento/magento2/pull/14801 we would not have anymore limitation that our DTO interfaces should have setter methods (which are being utilized by webapi framework for object instantiation). Thus, our entities should such as SourceInterface, StockInterface, SourceItemInterface etc., should be updated correspondingly.
4. Disable Default Source. Currently, it's possible to disable Default Source which potentially leads to unpredictable behavior both from front-end and back-end sides. We have a concept of Default Source/Stock for seamless migration of existing Magento merchants, also we re-use cataloginventory_stock_status table as an index for Default Stock data. Should we forbid to disable Default Source? Should we provide a possibility to build Single Source Inventory based on non-Default Source?
5. When all the variations of Configurable product are disabled, should we change "Stock Status" of Configurable to "Out of Stock", or just make Configurable product disabled as well?
6. Should we leave legacy Inventory index or it should be fully substituted by new MSI one? If we leave both, how these indexes should be synchronized? Currently, we re-use legacy index for Default Stock because it supports of Bundle and Grouped product Inventory indexation which we use in Single Source mode.
7. Should we keep the synchronization between Catalog and Inventory? For example, remove all the SourceItems and StockItems when a product is removed from Catalog. Ideally, if we are following principles of microservice architecture - not. This means that we need to have an ability to process an order (invoice, ship) if product mentioned in the given order is removed from Catalog. Issue gets more complicated, because currently MSI does not save own version of Stock Configuration data and re-use cataloginventory_stock_item which is deleted when a product is removed from Catalog.
   • Installing MSI we could remove DB constraint on cataloginventory_stock_item table CONSTRAINT CATINV_STOCK_ITEM_PRD_ID_CAT_PRD_ENTT_ENTT_ID FOREIGN KEY (product_id) REFERENCES catalog_product_entity (entity_id) ON DELETE CASCADE,``