I think you have made a really noble effort, but it seems there are fundamental problems with how the code is structured. As other have suggested, it may help to separate the operations into discreet parts, eg:

1. Broad phase: Loop through all the objects - do a quick test (eg, AABB) to determine which objects may be colliding - discard those that aren't.
2. Narrow phase: Loop through all the colliding objects - calculate a penetration vector for the collision (eg, using SAT).
3. Collision response: Loop through the list of collision vectors - calculate a force vector based on the mass, then use this to calculate an acceleration vector.
4. Integration: Loop through all the acceleration vectors and integrate position (and rotation if needed).
5. Rendering: Loop through all the calculated positions and render each object.

By separating the phases all objects are updated progressively in sync and you won't have the order dependencies you are currently struggling with. The code also generally turns out to be simpler and easier to change. Each of these phases is fairly generic, and it's often possible to substitute better algorithms after you have a working system.

That said, each of these parts is a science in itself, and can occupy a great deal of time trying to find the optimal solution. It may be better to start with some of the most commonly used algorithms:

• Broad phase collision detection: Spatial hashing.
• Narrow phase collision detection: For simple tile physics, you can just apply Axis Aligned Bounding Box (AABB) intersection tests. For more complicated shapes you can use Separating Axis Theorem. Whatever algorithm you use, it should return the direction and depth of an intersection between two objects.
• Collision response: Projection.
• Integration: The integrator is the largest determinant of the engine's stability and speed. Two popular options are Verlet (fast but simple) or RK4 (accurate but slow) integration. Using verlet integration can lead to an extremely simple design as most physical behaviours (bounce, rotation) just work without too much effort. One of the best references I have seen for learning RK4 integration is Glen Fiedler's series on physics for games.

I think you have made a really noble effort, but it seems there are fundamental problems with how the code is structured. As other have suggested, it may help to separate the operations into discreet parts, eg:

1. Broad phase: Loop through all the objects - do a quick test (eg, AABB) to determine which objects may be colliding - discard those that aren't.
2. Narrow phase: Loop through all the colliding objects - calculate a penetration vector for the collision (eg, using SAT).
3. Collision response: Loop through the list of collision vectors - calculate a force vector based on the mass, then use this to calculate an acceleration vector.
4. Integration: Loop through all the acceleration vectors and integrate position (and rotation if needed).
5. Rendering: Loop through all the calculated positions and render each object.

By separating the phases all objects are updated progressively in sync and you won't have the order dependencies you are currently struggling with. The code also generally turns out to be simpler and easier to change. Each of these phases is fairly generic, and it's often possible to substitute better algorithms after you have a working system.

That said, each of these parts is a science in itself, and can occupy a great deal of time trying to find the optimal solution. It may be better to start with some of the most commonly used algorithms:

• Broad phase collision detection: Spatial hashing.
• Narrow phase collision detection: For simple tile physics, you can just apply Axis Aligned Bounding Box (AABB) intersection tests. For more complicated shapes you can use Separating Axis Theorem. Whatever algorithm you use, it should return the direction and depth of an intersection between two objects (called the penetration vector).
• Collision response: Use Projection to resolve inter-penetration.
• Integration: The integrator is the largest determinant of the engine's stability and speed. Two popular options are Verlet (fast but simple) or RK4 (accurate but slow) integration. Using verlet integration can lead to an extremely simple design as most physical behaviours (bounce, rotation) just work without too much effort. One of the best references I have seen for learning RK4 integration is Glen Fiedler's series on physics for games.

A good (and obvious) place to start is with Newton's laws of motion.