Comment 2 for bug 493094

Some notes.

1) The current behavior of start on completely violates the principle of least surprise. There is no situation in which "start on foo \n start on bar" will do something the user actually wants, which means the user will always get something they didn't expect. Having the job fail with multiple start ons would be better than what we have.

2) we've said we'll keep 0.6 compatibility. There's been a lot of talk of modes and detection and separating jobs, when really the best way to do that would be to just /don't remove start on and stop on/. Using them can set off all kinds of buzzers and alarms and "you're doing it wrong" notices, but just leaving them in completes our backward compatibility with little additional effort.