SUMMARY

Scheduler properly reschedules a job that crossed its altitude limit to the next acceptable startup time and waits for its rescheduled startup time. However, this prevents further jobs in the list from executing at that moment: following the ordering rule, they are rescheduled after the restricted job.

This can be worked around by automatically reordering jobs each time the list is evaluated, but that feature is often disregarded because it doesn't (yet) address obstructed horizon.

STEPS TO REPRODUCE
1. Schedule two asap jobs, first of which has an altitude restriction, second of which has none (warning: there is a minimal altitude limit hard-coded whatever the value of the restriction box).
2. Execute the plan so that while running, the first job violates the altitude restriction, but not the second job.
3. Observe behavior

OBSERVED RESULT
First job is aborted, and rescheduled hours later when the altitude restriction can be complied with. Second job is shifted to start after first job, often on the next night and doesn't execute right now although no restriction would prevent that. If happening on the beginning of the night, this wastes the whole night.

EXPECTED RESULT
The behavior is compliant with the algorithm. However, it would seem more natural that the violating job is aborted, and the next is processed.

SOFTWARE/OS VERSIONS
Windows: 
MacOS: 
Linux/KDE Plasma: Ubuntu 18.04 - KStars 2019-02-21T21:29:33Z built from git state ~3h before that time.
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

This is not a bug, this is how the algorithm was designed. Changing the behavior to address this issue would be an improvement.

First, if currently running, Scheduler could avoid updating the current schedule of subsequent jobs after such violation, unless there are no jobs left to run. Scheduler would then continue with the next job that is ready to run.

What is the job that is ready to run? Restriction violations are detected while scheduling and marked with a warning icon in the list, so the end-user is aware of possible issues in that case. Violations may also appear because of a runtime delay (customizing how long accessory steps take is not implemented as of now). Well, in order to manage those two situations, when running, Scheduler should decide to abort subsequent jobs that are too late based on their startup time (this is already in the code), without changing the schedule (this is not).

To relax the situation (but this is a further improvement, not needed right now) and avoid delaying the whole schedule too much, Scheduler could abort jobs which have less than 50% of their duration remaining based on their startup time.