They smell a bit similar, but are maybe not?

slave-squatter definitely is involved here.

Without reservations:

• a job of weight 2 will happily run on a 2-executor slave.

With reservations:

• a job of weight 2 will NOT run on a 2-executor slave.
• a job of weight 1 will NOT run on a 1-executor slave.
• a job of weight 1 WILL run on a 2-executor slave.
• a job of weight 2 requires 4 available executors.
• a job of weight 3 requires 6 available executors.

Smells like a doubling, or something being subtracted twice?

It gets better (or worse).
The slave (with 8 executors) was running some builds; there was a single executor available. I then tried manually requesting a build of a simple job (weight 1).
This caused all idle executor threads inside the Hudson server to crash! The build executor status showed "Dead!" with a link to this report:

java.lang.IllegalArgumentException: fromIndex(0) > toIndex(-1)
at java.util.SubList.(Unknown Source)
at java.util.RandomAccessSubList.(Unknown Source)
at java.util.AbstractList.subList(Unknown Source)
at hudson.model.queue.MappingWorksheet.(MappingWorksheet.java:311)
at hudson.model.Queue.pop(Queue.java:753)
at hudson.model.Executor.grabJob(Executor.java:175)
at hudson.model.Executor.run(Executor.java:113)

The running builds continued without problems to completion, and their threads appeared to stay functional. The dead threads were unsalvable and I had to restart Hudson.

Simple patch that corrects the reported bug for the situation where a slave only has a single active reservation. It will not work if the slave has multiple overlapping reservations.

The root cause is that active reservations are being double-counted: once by the hudson.plugins.slave_squatter.LoadPredictorImpl, and again by hudson.model.queue.LoadPredictor.CurrentlyRunningTasks. That leads to two separate failures: the first is that double-counting the reservations makes the scheduler think that the machine is busier than it actually is (the original ticket). The second is that the double counting can cause hudson.model.queue.MappingWorksheet to generate a maximum predicted load that is greater than the total number of executors, but does not clamp the prediction down to the actual total number of executors (see JENKINS-8882), which leads to the "Dead!" executors.

I have a simple patch (attached) that works as long as the slave only ever has a single active reservation: it will fail if the slave has overlapping reservations. Basically, the patch is a hack that reports "negative load" for currently running reservations to counter-balance the extra load reported due to the double counting. A better approach would be to fundamentally redesign the slave-squatter's LoadPredictor API so as to only ever report predicted load and to exclude all currently-running reservations.

Assigning to Kohsuke (slave-squatter author) so he can comment on the best way to address the double-counting of reservations.