This seems to create a tight coupling between the state-slice and the actions, which I see some concerns with. Likewise with the next section in which actions are specifically namespaced to a slice of state and the reducers are used to generate action creators.

In my experience, I’ve seen benefits from treating actions as representative of user intent (“increase thermostat temperature”), as opposed to expressions of what to do with the state (“increment the thermostat counter”). The latter is then up to the complete collection of reducers to determine how the intent gets mapped to state mutations. I find it provides better separation of the application’s purpose from the specific layout and implementation of its state.

E.g., if I decided to add support for heating as well as air conditioning, maybe there’s a new piece of state that needs to be informed when the thermostat temperature is changed. If the action is intent-driven, all I do is add a new reducer to handle the same action. If the action is specific to a slice of state, then I now need to define a new action to update this new slice of state, and make sure it gets fired everywhere that the other action could possibly be fired from.

I think you’re spot on about the exported type definitions being symptomatic of a problem, but I’m not sure the proposed solution covers a large surface of desirable use cases.