gistfile1.txt

Yes, this is a contrived example just to show off what I'm talking about...

init.sls ( I used /base/be_cool/init.sls)
========

do_something_cool:
  cmd.run:
    - unless: '[[ -e /tmp/dsc.no_run ]]'
    - name: echo 'done' > /tmp/dsc.log && touch /tmp/dsc.report && true

watch_it:
  file.append:
    - name: /tmp/dsc.report
    - text: We did something cool!
    - watch:
        - cmd: do_something_cool


Pretty simple - watch a command and run a report when/if it executes...test it:
  rm -rf /tmp/dsc.* ; salt-call -l debug state.sls be_cool

Nothing special...The job runs, the log file is produced and a report generated:
  root@storx22:/etc/nginx# more /tmp/dsc.report
  We did something cool!

Now run it again, with /tmp/dsc.no_run so the command does NOT execute:
  echo "foo" > /tmp/dsc.report ; rm /tmp/dsc.log ; touch /tmp/dsc.no_run ; salt-call -l debug state.sls be_cool

Notice, the command did NOT run (no /tmp/dsc.log file so we know the command didn't execute) BUT the report got regenerated:
  root@storx22:/etc/nginx# more /tmp/dsc.report
  foo
  We did something cool!

Thats why I think giving states the _option_ to use cmd.wait + -watch semantics is important.  It would prevent a target from running unless the 'watched' item actually changes...
Sometimes it just isn't safe to run a target just to see if the target is up to date.

P.S. 
I _think_ it might lessen the need for overstate too, as it gives you finer control over when a target actually runs.
But I don't have an example of that atm.