Yup, that (your use of the algorithm and what it was/was not intended to do) makes sense. I'm not going to drop the discussion quite yet, however, because EternlKnight's original question did seem to relate to some of the things that your algorithm didn't address, but I suspect it may give a clue as to how to get to a decent solution.
I did not apply this algorithm to prevent light dynamic objects from tunneling or to solve the heavy-on-light problem. But it seems applicable if you have a separate position projection phase in your algorithm. I think if you solve your constraints with velocity impulses then you can do whatever you want in a separate position projection step (see our discussion of Jan's Impulse Based Dynamics library). You don't even need to consider mass at that level.
I'd agree with that, though for the purposes of heavy-on-light stacking, the position projection is not really at the root of the problem, it is the velocity stuff (which is all bound together if you're using Verlet, but that's another nasty issue altogether) that is difficult to handle. In my opinion, the fundamental problem is that the obvious way of iterating velocity constraints pairwise (using the standard collision resolution formula from high school physics) breaks down in 1D if you look at the "sandwich" problem:
A-> B <-C
with A.mass = C.mass >> B.mass (that's a "much greater than," not a shift). The velocity constraint is satisfied only when A.v < B.v < C.v. The difficulty is that the only reasonable way to resolve each pairwise velocity constraint is to do a collision with some coefficient of restitution, and unless you allow explosive coefficients of restitution, the number of iterations to get those constraints satisfied grows as O(sqrt(A.mass/B.mass)) if my back of the envelope calculation is right. This isn't horrendous, but it's not great, either - once you get up to a 100:1 ratio, you're probably pushing the limits of how many iterations you're going to be able to afford with all the other stuff that happens in your loop.
BTW, global solvers, such as CG do not have the heavy-on-light problem (at least not as bad).
Right, but global solvers have their own issues as well, so people are somewhat loathe to use them. Philosophically, at least (and for the purposes of simplicity in code), there is a lot to be said for considering a contact to be a purely local construct - Box2d always does this, no?
So the real question is the following: using _only_ the information locally available to a single contact, maybe including information from previous iterations, is there a way for the contact to figure out how to alter its response between two bodies so as to accelerate convergence when those bodes are also acted upon by other contacts? [that is, without explicitly figuring out chains of contacts, which starts to head into global solver territory] I'm not sure myself - maybe this is already a solved problem, I guess that's what I'm wondering. If not, it seems that the idea of looking at the degree to which a contact's hard work has been screwed up by other contacts when it comes time for the next iteration might be a pretty good local indicator of how the contact should change its behavior - for instance, if I put myself in the shoes of a contact, and every time I give a particle some velocity it is exactly reversed when it comes back to me during the next iteration, it seems pretty likely that I'm pushing that particle up against a solid wall and I might as well just zero out velocity altogether and handle the pressing body's velocity accordingly, skipping the whole back and forth dance that would otherwise slowly dole out the required momentum change. But maybe that's not a very promising way to handle this type of situation, I'm not sure.
As an aside, is the heavy-on-light effect the reason box stacks start to twitch when you build too high, or is that something else? Very roughly speaking, the mass ratios where you have single-box stacking problems seem similar to the number of equal mass boxes you can stack without dancing, but this could just be a coincidence.