I suppose it depends on what you mean by "state-change manager".
My understanding has always been that a controller's job was to translate user actions into domain-level operations to be carried out. You might start the foobazifier by clicking a toolbar icon, pressing a keyboard shortcut, or selecting a menu item, but they all have the same effect. The controller's job is to interpret those user actions to determine the required effect. The model's job is to understand what that effect means and update things accordingly.
In practice, of course, it has never really been quite that simple. Views tend to have metadata (such as the current cursor position in a document or zoom level) that are also maintained by commands from the controller, so not all data is stored in the model, only the important, domain-related state. Observer patterns get implemented so that the model can remain independent of any particular controller/view pair, but it still has to provide both an API for updates from controllers and a defined set of events that interested modules can observe.
In any case, the model's role is not just to be a thin wrapper around the database/file system/whatever. It is also the guardian of "business logic". I think one danger with the term MVC is that it suggests a system composed of only three modules. In reality, MVC is a high-level architectural pattern, and in non-trivial applications all three of those components are going to need a lot of internal structure as well. Representing domain concepts and persistent state may well be at the core of the model, but just about any code that works entirely in terms of domain concepts probably belongs within the model component somewhere.