During the time I was implementing the PoC of this feature I needed to make some minor modifications to the design. They mainly have to do with when a job's queue gets taken into account when creating equivalence classes. It's no longer an all or nothing sort of thing if such a situation exists on the system. When creating a equivalence class, a job's queue is looked at if it falls into the defined criteria. This means you can have some jobs that use their queue and others that do not.
One is another thing that came up during the discussion of the feature. As designed, it is no longer possible to determine the political ordering of the jobs via the log files. Prior to this feature the order of 'Considering job to run' lines would give the political order. Now when a job can't run, the entire class is marked that it can't run. You now get a political ordering of equivalence classes instead of jobs.
I think this is one of those things we need to give up for scalability. Complexes are growing as well as the number of jobs on those complexes. We need to be doing less work per object (job, node, etc) in order to keep up.
That being said, there is functionality in PTL that will change. Right now there is a cycle object and a member of that object is the political order. This will now give you a political ordering of equivalence classes. The only way to get a political ordering of jobs is to jump through hoops to make sure each job is in its own class.