It seems like it is a common problem that the objects that are updated first will dominate the objects that are updated last. So I was wondering how other people circumvented this problem.

One idea I had was reverse the order you updated the objects every frame. So far it's working well.

What do you mean by "dominate" ?
If you explain the problem better, maybe we can give you a better solution.

I think he means, if an object is updated first, it checks collision against the others posistion. But when they update they will be checking against the objects updated posistion. At least thats how I understood it :)

The objects that are updated first get first say in all physics calculations. The first object gets its full movement until a collision, while the second one has to then move with that object in the way, when in real life they would move at the same time (creating situations where sometimes there wouldn't be a collision in real life but there is in the game).

This seems like it would be a general problem in most games that use collision detection, I know it is in mine, though I think I fixed it with my update order reversal every frame.

Heres a thoguht, two posistional variables. You collision detect against the posistionA, but then write the results to posistionB. When everyones done, copy posistionB in posistionA and use it for rendering.

One way you could solve your problem would be to make each object have a position and a velocity. During the collision detection/response, you only affect the velocities, and after the physics routines are done, update all the positions based on the velocities.

Extending your original idea, you could sort the update order by any properties that might make for interesting but not entirely realistic behavior. For instance, velocity: fast > medium > slow, or based on type: Player > associate > neutral > obstacle > aggressive, etc. The drawback to sorting your list would obviously be the time it takes to sort it for large lists. An order by Velocity list would have to be sorted every update, for instance.

It seems like it is a common problem that the objects that are updated first will dominate the objects that are updated last.

The way this is done in "real" game physics engines is to first calculate all the collisions and other constraints (such as joints), and then, in a second pass, solve for all the constraints at the same time, typically using a big-matrix LCP solver. Packages like Havok, PhysX, ODE, Bullet etc all do it that way. Also, JigLibX and BulletX for XNA do it that way, too.

A slightly simpler and sometimes good enough solution is the one already suggested here: solve the constraints in velocity space, rather than position space. Typically, you will apply penalty impulses from detected collisions, and then accumulate all the impulses into velocity, and finally solve for the new position of all objects when all impulses/forces/velocities have been resolved. The draw-back is that each impulse doesn't know what the others are doing, and thus the overall solution isn't as "globally consistent" as with an LCP solver. This will be noticed mostly when colliding in corners, or colliding with multiple objects at the same time.