This is interesting and possibly more complicated than I first thought. It makes sense to me that if a <flow/> stops its enclosing step (and job) should stop. If an externalized Job in a JobStep stops, though, maybe that was intentional, and maybe the parent job wants to look at the stopped status and decide whether to stop itself. Also, if I send a stop signal to a job that contains a nested JobStep, should the nested executions be stopped as well (and how will the framework know how to do that). It might turn into a bit of a can of worms here.
I propose that we should extend the stop signal from a nested flow right away in 2.1.7, and then leave the rest to stew for a bit. Does that make sense? If you have some test cases or usages that led you to discover the issue, we could use those to explore the problem.