Configuration Drift and Next-gen Configuration Management

Lately I've been thinking about the concept of config management, and I've come to some conclusions:

1) Configuration management has the same problem object oriented programming and imperative programming have: state is intermixed with identity and behavoiur. This makes it more difficult to reason about.

2) Configuration management is too low level: One should not describe the state of configuration to keep, but the desided behavoiur of the system. The configuration part should be automatically derived.

3) Configuration management breaks locality: If a config manager is running, the point of change of the system is not in the config files anymore. If I have a problem and the documented solution tells me to change a particular configuration, an additional step is added toward the solution. Also, if something doesn't work as expected, configuration management must be additionally investigated as a possible source for the problem.