Limits of ChangeNotifier granularity for widget rebuild isolation

When using ChangeNotifierProvider to expose application state, the boundary between a single coarse-grained notifier and multiple fine-grained notifiers determines how widely notifyListeners propagates rebuilds. A common caution is that consolidating too much state into one ChangeNotifier can widen rebuild scope, but no concrete threshold exists for when splitting state into separate providers becomes necessary.

In a widget tree where several sibling widgets observe different logical slices of the same state object, propagation behavior depends on whether those slices are exposed through separate ChangeNotifier instances or consolidated into one. The uncertainty lies in how to structure notifiers when state slices share derived data or require coordinated updates, since consolidating them into a single notifier increases rebuild scope while fragmenting them may duplicate computation or complicate ProxyProvider dependencies.

What practical signals indicate that a ChangeNotifier has become too coarse-grained for efficient rebuild isolation? How should shared derived state be modeled when sibling widgets need independent rebuild boundaries? Does the Provider package impose any architectural limits on splitting a single logical state object across multiple ChangeNotifierProvider instances?