After almost exactly a year of playtesting the HP threshold system, I'm back in this thread. I've edited the OP to match the current status of the system at this point.
Playtesting started on a group of 5 level 4 PCs, who are now almost level 9.
The PCs are a level 8 battlemaster, a level 8 assassin, a multiclass level 4 thief/4 shadow monk, a level 8 tome warlock of the fiend and a multiclass 7 lore bard/1 fighter.
They are not control specialists, but between the bard and the warlock they do have enough control to turn the tide of battle.
Up to this point, the threshold system has worked well. It doesn't come up often, which is great, but when it does come up, it makes a difference.
The latest example happened last session. The group encountered 2 chimeras, and the bard rolled high initiative. He cast hypnotic pattern on both chimeras, and both failed their save. Normally, that would've turned a challenging battle into a cakewalk. With the threshold system, the chimeras were just charmed, instead of incapacitated. So the fight went on, with the party fighting off one of the chimeras while the bard used his charisma and the charmed condition to keep the other chimera in check, eventually persuading it to go away (good thing he can speak draconic...).
Anyway, I'm aware that this system probably ended up being too cumbersome to be easily plugged into anyone's campaign. It's a complex solution to a complex problem, but it's working great for us, and I just thought I'd share our experience.
Ok so to start i want to look at your described fight and the claim... marked in bold.
Hypnotic pattern full on regular rules:
Both beasts are charmed to the bard and get no actions and have speed zero.
Smart group of PCs then attack *one* beast at a time with **at best** a complete set of attacks on that one before it gets a chance to act (assumes a lot of ready attacks keyed to "when the bard attacks.) Then they have to repeat the attack routine against the other one. Maybe that is a cake walk if they can one shot the chimera but they do end up expending the attack rountines against both because the other one cannot actually leave due to the incapacitate thing (and you have to wonder what will happen after the charm drops. It might just leave on its on.)
With your new interpretation they still squared off against one chimera and instead of them getting a full set of ready attacks it may have gotten off its first set of attacks too. So the net result is the chimera gets **one additional** turn of attacks off (at best.) However, the other chimera being charmed and active - can be convinced to leave during the ongoing duration - in other words the charm can be exploited to remove the creature from the battlefield.
So you traded off allowing the killed chimera one additional turn of attacks with having the other chimera not need to be dispatched - no resources lost, not potential for it to strike back if not killed in one alpha.
So, it seems like it did not make a major difference to how the encounter could have played as far as the cakewalk vs fight off kind of thing. it altered the actions taken but not the difficulty.
A side-point i am seeing here is - there are times when the removal of a negative condition can result in negative results - removing the incap meant the other chimera was not stuck there and let the charmed still be used to keep him "in check" and even get him to leave which is perhaps better than having it still there waiting for the opening to attack once they turn their attention to it.
Second point - you seem to have chosen a number of effects like charm person, charm monster to basically exempt from this rule - while leaving suggestion and others affected. I can imagine its because you judged them as "soft" controls or something. But in fact as you show here, the charm effect without incapacitation can result in just as much impact as any hard control could - it effectively enabled them remove the creature from the fight. So i see here something i saw when i looked at your spells lists in the opening post - seems wrong to exclude charms spells.
That said - I myself recently put up a post pondering the balance concerns of the various "save or..." attacks/spells especialy when they provide ongoing without re-save conditions. My suggested approach to it was not to initiate HP thresholds and track effects vs thresholds as things go along and come up with partial effects but instead to use the existing three way save mechanic - require the targets to keep making saves against a "save or..." ongoing effect (at the end of their turn) until one of three things happens -
1 - the spell duration is ended by time elapse or by defined events
2 - three saves are failed in which case the spell effect goes on without saves needed.
3 - three saves are made at which point the spell ends.
(red poker chips in hand - make save give it back to GM, fail save put it down on table to show effect)
basically as long as you have not made three saves or failed three save the spell/condition is still "taking effect" and not yet set.
Each turn/round where you fail a save you get the effect. Each turn/round you make it it lifts with no condition applied as long as it is still "taking effect" and not "set in."
So the loss of one save is not that severe - one turn of effect vs full duration - and the situation remains in play and i do not have to pick a bunch of lesser conditions or pick which spells to include or not. The only spells excluded would be ones which already allow a re-save each round for ending effects.
Also note that this cuts both ways - a single made save does not mean wasted spell. They still have to make saves and can get affected by any failure or longer term by three failures.
It also keeps HP from being made into even more of a buffer than it is now and prevents CON from being even more beneficial (every PC i have ever seen has cons of at least 12-14 range at start when point buy is enabled it is almost always the second or third best ability. If it played a direct role in resisting control effects, that would jump it up on priority for many players IMO)
So, i see your point about what the problem is and share similar concerns and i applaud you for an interesting approach and one that you seem to think works for your group. However, i find problems with your implementation and see issues with your depiction of the impact (albeit based on just one graph about one use case.)
Many Many thanks for the follow-up - i would not have seen this post/thread otherwise.