The optimizer recognizes that the variable `condition` and the condition with the guard's if-statement are the same (edit: inverses actually), so within the if-statement's body, it can assume that `condition` is false. But when other guard cases are merged in, that's no longer the case.

In other words, the general optimization is to convert

    bool A = condition(); 
    if (!A) { f(A); }

to:

    bool A = condition();
    if (!A) { f(false); }

i.e., that we can assume an if-condition is true within the body of that if-statement. The problem is that the check-widening reuses the body of the if-statement: the code

    bool A = condition();
    if (!A) { f(A); }
    bool B = condition();
    if (!B) { f(A); }

is converted by check-widening to the first snippet above, which then becomes the second. Sanjoy's observation is that guard-widening is almost correct (we still want to pursue this route) because `f` (the deoptimization escape) is really what we want to call in both cases, but we just need to get the value of `A` right by somehow letting the optimizer know that we're reusing the if-body and that it can't assume anything about the condition that got us there.

Also, this is really really clever and I enjoyed the post, OP!