This seems like a somewhat dirty quickfix that overall works with surprisingly little collateral damage. It doesn't even fix the original cause of the issue, which I would thought would have been the obvious choice for fixing it, i.e. when a tumbler hits the vertical wall, still add the whole y-velocity to the y-position, and invert whatever distance remains from the x-velocity after subtracting the distance to the wall, and add it to the x-position. The trajectory stopping at the wall during a frame in itself is a flaw, though it is barely noticeable. One could probably design some pathological examples where it's annoying or strange nevertheless.
Either way, it seems like the main issue in the bigger picture is that fallers work with distance, while tumblers and flingers work with velocity.
Flingers must use velocities, and I guess because of faller physics being holy, they must use distances. (If they weren't holy, there would be an obvious unification of physics: Just use realistic physics by having fallers affected by gravity, and death is determined by impact velocity for everyone. In that sense moving to distances for the tumbler check is a step backwards to me, if anything.)
So at some point a conversion between distances and velocity must happen.
In 0.6 it happened by estimating the velocity of a flinger after having fallen 126 pixels, and everything was fine except the issue from the beginning of the topic which arises from some unrelated issue, namely some sloppiness in tumbler movement code.
In 0.7.18, you swept the necessity for converting between distances and velocities under the rug and "fixed" the issue by removing downward flinging objects. It works with surprisingly little collateral damage, as everything overwrites rather than adds to velocities (comic physics rather than real physics), and thus everything that sets an upward velocity is not affected. Either way, if you ever wanted to add rather than overwrite velocities (which would cleanly solve Nepster's concern that explosions from above can actually save fallers, but also disallow certain other things that work under current physics), or have downward flingers, here's how the conversion between velocities and distances should be done:
Given the desired y-velocity v (of the flinger object; or in case we use addition rather than overwriting, the sum of the two y-velocities), we need to estimate the distance traveled s to achieve the velocity v under acceleration a (=gravity), starting with 0 velocity. This is computed via s = v2/(2a).
So if you want to stick with the 0.7.18 fix instead of fixing the underlying cause, I propose to make the following addition:
If a lix encounters a downward flinger that flings down with vertical velocity v, instead of initializing the pixels-fallen-counter with 0, initialize it with v2/(2a), where a is the gravity constant in the game.
That way we can have downward flingers of any speed with consistent physics, rather than some arbitrary velocity cutoff (currently somewhere undetermined between 2 and 24 pixels per frame) from which on we consider the physics to be weird and thus disallow faster downward flingers by convention.