ngrx/store vs componentStore: scoping boundaries for selector memoization

Context

ngrx/store selectors created with createSelector memoize based on object-reference equality, while ngrx/componentStore ties its state lifetime to the host component's destruction. Both behaviors are documented, yet the framework does not prescribe a default rule for deciding which store type owns a given piece of state.

Constraint

A feature module may be instantiated multiple times across the application (e.g., a reusable dashboard widget). If the feature uses global store, selectors remain memoized across instances but state persists for the application lifetime. If it uses componentStore, each instance gets isolated state that is cleaned up on destruction, yet selectors that receive new object references from parent components on every change-detection cycle lose their memoization benefit.

Open decision

Teams must choose a scoping strategy without a documented convention, balancing memory retention, cache reuse, and the risk of duplicated state when both store types coexist.

What criteria should drive the choice between global store and componentStore for reusable feature state? How can selector memoization be preserved when component-bound inputs frequently produce new object references? Does mixing both store types in the same feature module introduce ownership ambiguity that outweighs the isolation benefits?