If you disable backup pooling or set backup threshold really high, you will essentially be hopping at a random threshold. A new round could start at a new pool when your current least-share pool is at 10% or 300%.

I assume you are giving each pool a table of random block find times (randomly generate a high-precision round percentile 0% to 100%, turn that percentile into number of individual hashes required using correct math, turn that into times using hashrate), and then are simulating the switching and share percentages earned. I too am curious in your simulation, how much time is being spent mining beyond the "optimal" range, say if the threshold was 1.8? Could you run a histogram with difficulty switch points for your six-pool example, so we can visually see how long we spend in proportional rounds. I'd be interested how long they actually tend to go.

For more interesting real-world factors to model, analysis could be biased with a 'pool hop-in' time delay (like jumping 5 minutes after block find), and a 'wrong pool hop error rate' that reflects what people are seeing with early block-detection methods, when they get incorrect blockfinding because they aren't getting info from the pool that actually found a block, and jump to a false-positive.