Tricky issue where jobs which were scheduled at the same time would not be picked in the right order, because qSort is not required to be stable, that is, is not required to leave items which compare equal at the same rank in a list.

This situation would cause another job than the first in the job list to be picked as first job when the algorithm rescheduling close jobs executed, leading to an unexpected reordering of activities.

User rankinstudio offered .esq and .esl files which can be used to reproduce the issue in the forum, "Ekos Scheduler Changes - Need Override to Stop Rescheduling". All other test vectors are suitable, as long as the problem is understood.
An interesting test vector for the problematic use case is one with jobs that are evaluated, whatever the constraint (altitude/twilight/moon), to start at the same time or under 5 minutes from each other.
When option "Sort jobs based on altitude and priority" is disabled, any job with a positive score at the time of test will be able to run, thus will be scheduled at the current date.
When option "Sort jobs based on altitude and priority" is enabled, preconditions are the same, but as those jobs will be sorted per altitude before being rescheduled, leading to a different order.
All in all, the test vector must be built in such a way that multiple jobs are scheduled close to each other, and are re-scheduled by the Scheduler with an offset corresponding to their duration, or min 5 minutes.
In this situation, the objective of the test is to make sure the Scheduler is picking the good first job to run, then is re-scheduling other jobs from the startup time of this first job.
When the option "Sort..." is disabled, test must verify that it is the row-first job.
When the option "Sort..." is enabled, test must verify that it is the highest-altitude + highest-priority job.