I understand that maintaining a single type is still technically possible in the new system. However, my point is not about technical feasibility, but rather about how Collection 2.0 will be perceived and adopted by the general user base.
When a product introduces additional features, most users naturally assume that it is the “better” or “recommended” way to use it. In such an environment, assigning multiple types to a single document is likely to become the default behavior for average users. Consequently, maintaining a “single type per object” workflow will be confined to a small minority of power users who already have a firm, established methodology for data management.
This leads to a fundamental question: Is allowing multi-types truly a better methodology? My feedback is that it might not be. While it may seem like “supporting more features,” I believe this approach treats edge cases as core logic, which can result in unnecessary architectural complexity.
Personally, I believe a system that provides high scalability through a few, strict rules is superior. Instead of adding layers like multi-types to handle exceptions, it is generally better to keep the core structure simple and intuitive—similar to Object-Oriented Programming (OOP)—and let scalability emerge from that clarity.
The “Object Collection” I proposed offers more versatility with a much simpler structure. Even with this approach, it is very easy to configure a setup where a document appears to have multiple types. In other words, I believe it is structurally superior (upper compatible) in every aspect compared to the current direction.
The only real challenge is the need for deeper consideration in designing a natural and convenient UI/UX. While splitting the same topic into individual documents for different types is scalable, it can certainly be cumbersome. We need a UI/UX that allows for smooth and intuitive interaction.
The ideal experience should be so seamless that users feel as though they are editing a single document, while in reality, the data is stored across multiple documents according to their types. The concept should be clear: “The user can treat the whole as one document, but also has the power to control individual parts as needed.” (For instance, when creating a query for an online shop, you don’t always need all related information; exposing unnecessary data only adds confusion.)