I noticed you have made a lot of commits to this plugin recently - hoping you would be interested in looking at this

I see your points.
But Jenkins is not designed to decide build results by results of downstream builds, and I do not plan to add features out of that design of Jenkins.

In that case, people seem to use Promoted Builds plugin (https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin).
For build execution exclusion, you can use Throttle Concurrent Builds plugin (https://wiki.jenkins-ci.org/display/JENKINS/Throttle+Concurrent+Builds+Plugin) .
Or, though I haven't ever used it, Multijob plugin may help you (https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin).

Would you see whether above plugins can meet your requirements, and let me know what they cannot meet?

OK, I understand what you're saying. Here is an alternative suggestion that would help me: can you add an option so that, when the plugin is used as a build step in a matrix build, it only runs once for the whole job, instead of once per axis of the matrix? That would still allow me to trigger the deploy job only once, and have the build job fail if the deploy job fails.

Only aggregations of publishers can run for whole a matrix project.
It sounds good to extend Any Build Step plugin to allow a build step run as a aggregation.

I decided to start using the Build Flow plugin to orchestrate this behavior. I just create a build flow that orchestrates the build, deploy, and integration test run against the deploy environment. People can run the "flow" job and watch the whole process, and if something fails then the "flow" is marked as failed. I think this is cleaner.