Yes, you can define stores in separate files, and you can actually reuse a container as a whole (with its ActionProvider decorations) since it’s a component. If that makes sense in your domain. But if you do (re)use it, you get it as-is; you can’t cause regressions in other domains that it’s being used in since it isn’t global.
When I look back at how things evolved in Bridge, lack of visibility in itself wasn’t the problem. The real problem was in extending the scope of modules like stores so that they could accommodate multiple, different domains (e.g. screens.) Duplication is actually a less harmful strategy here.
If we get to a point where defining stores is very cheap and easy (which is already halfway there with the abstractions we have for the caching layer and for remote requests), we don’t need to create those cross-dependencies between consumers anymore. Compose a “new” store with the parts that you need and add to it the domain-specific functionality.
We already do much of this with components. We can apply the same concepts to those traditionally-monolithic entities too.
Using a single store to represent the state of the entire application feels almost like Ember where you have access to everything. If I’m in domain X, I should not have access to things defined by domain Y. It just feels like one massive-scale leak.