One challenge here is that these functions wrap another expression with unknown state information, so the use of a local inside of the expression might conflict with the temporary local being added. Means: If tests pass currently, that's more of a coincidence because either there's no test cases causing such an issue or the functions are used in a way inside of the compiler that it cannot happen (but still might in the future).

Hmm. So how we can do this properly?

ping. Could you make some suggestions how we could improve this solution?

Hmm, thinking. If there's a local.set or .tee inside of the wrapped expression, the respective temp. local should actually be blocked still if it is used afterwards, so conflicting with inner locals shouldn't be an issue.

Remains the question if this.currentFlow is always the correct flow. Appears to be the case for makeIsFalseish since that's used in proper order on ! unaries only, but makeIsTrueish has more call sites. The scenario to look out for is that makeIsTrueish is called immediately after the expression it is going to wrap is being compiled, like any pattern of let expr = compile(...); expr = makeIsTrueish(expr) would be ok since currentFlow is guaranteed to be correct in this case. If it turns out that all call sites are safe, we should then document this on both makeIsFalseish and makeIsTrueish so future users understand the implications and don't accidentally call it at the wrong places. For instance, someone might expect that calling those is independent of context, which it isn't anymore due to adding a temp. local to the flow, which must under no circumstances overwrite a blocked local.

Great, so this changes can't broke current flow analysis?

Haven't checked all call sites of makeIsTrueish yet according to the scenario outlined above. Depends on those :)

@dcodeIO wdyt about revisit this? Will be great improve compatibility

Closed for favour to #933