I'll hazard a guess and hypothesize that one or more of your device administrators occasionally does not follow through with a copy run start or write mem command after making a change.
If that step is forgotten and the device reboots at a later date, the change is lost, potentially causing an outage for your customers who rely on that device.
If this is the cause for the request for the NCM automatic detection of change and subsequent automatic copy run start action, I"ll offer the potential negative consequences of an automatic write mem firing off from NCM.
If a change happens to cause problems, you can relatively quickly recover from it with a reboot of the device as long as the change is not written to memory. If NCM automatically writes that change to memory, there's no recovery with a reboot. That means someone will have to travel to the device, console into it manually and revert the change.
It's hard to take out the human factor, but training your team to write memory every time may be a best solution.
One alternate is to run a daily scheduled / automated script across all your devices: copy run start. I work with a team of Network Analysts and sometimes I see discrepancies between startup and running configs, indicating someone didn't write memory, or indicating the running-config and startup-configs have not both been downloaded by NCM since the last running-config change was made.
I only download the startup-config weekly, and it gives me an opportunity to see if everyone is writing memory as they should. ACS lets me see which of us missed that command and helps us all standardize our processes.
An automatic and immediate copy run start takes away your option to use Cisco's "reload at" and "reload in hr:mn" comands. They allow you to work on a remote location and recover from mistakes with a scheduled reboot. An example of when this is useful:
1. A remote site needs some configuration changes--it's a long drive or plane flight to do them locally.
2. You are concerned that the configuration changes you're going to make could make the site lose remote connectivity.
3. Before making the changes, you issue the "reload in 10 minutes" command.
4. You make the changes and they're incorrect--the site goes down. In ten minutes the device will reload and you'll regain remote access, saving hours of down time and travel costs.
5. If your changes were successful and the reload is not necessary, simply cancel the reload and move on to the next project.
6. But you do have to remember to write memory or copy run start, or the next time that device takes a power outage your changes will be gone.
If that fail safe solution (reload at or reload in HR:MN) is useful, then having NCM immediately write mem or copy run start when RTCD discovers a change removes that fail safe option.
Swift packets!
Rick S.