@ LorenzoGatti That was my instinct, too, which made me wonder as to the specifics of my implementation, and where I'd.. gotten it wrong. With constant forces such as the mouse joint, it would bounce off on an initial swing (if the response was made elastic) then sink straight through. Is it to do with the ordering of resolving collisions, applying outside forces / impulses, and the integration itself?
@Krohm I understand your point fully about tools and libraries already existing to tackle this problem (box2d suffers from this also, you have to use edge chains I believe for static objects in sequence). However I do also view this as a learning experience and I value the process of solving the problem. I don't have a tight deadline or anything, I quite enjoy getting lost in the intricacies of physical simulation!
The main issue I have at this point is that I've seen from SacredSoftware's implementation that it is possible to get a more general solution, through the use of sorting collision priority based on which collision has a greater surface area of penetration in a given timeslice (or rather, time step with a threshold, as of course CCD would only really solve one at a time so you have to step forward and test a little). What puzzles me is the two facts that a) It does not function correctly without positional correction, and b) It gets stuck on an edge even in the case of a single box. I suppose if it's correcting it to the EXACT edge position, when it moves back down it would maybe get snagged on a corner? But is that correct behaviour?.. It's not common to many others, which makes me think the penetration resolution isn't quite correct, in terms of initial contact times.