Вместо итеративного алгоритма, можно подойти к расчету до пересечения кого либо, т.е. каждый объект имеет вектор движения и его коллайдер (в случае с простыми геометрическими фигурами типа сфера или квадрат с параллельными осям поверхностями это простое уравнение, в крайнем случае можно свести все к треугольникам или если 3d то тетраэдрам и строить объекты уже из них, ну а для оптимизации, не считать самостолкновения), получив точку, считаешь касательную к колайдеру и считаешь силы и правишь вектора скорости, а там уже по ситуации (нужно ли добавлять вращение, а то тогда уравнение пересечения будет сильно сложнее), тут же можно учитывать упругость столкновения.
Так как для большого количества окружностей считать уравнение будет экспонента (квадрат от количества) то можно уже вводить оптимизации сортируя по суммарной скорости между объектами (список вести для каждого), т.е. нет нужды искать пересечение между объектами, летящих друг от друга или слишком медленно
С другой стороны, после столкновения, пересчитывать проверку пересечения придется только для этих двух столкнувшихся объектов, т.е. трудоемкость линейная
upd. если подумать, оптимизация не такая простая, но грубые оценки можно делать учитывая тоносительную скорость между текущим объектом и исследуемым, а так же его расстояние, т.е. чем быстрее и чем ближе объект находится тем выше в списке на проверку он должен быть (т.е. разница скоростей между текущим и исследуемым/расстояние между ними), к сожалению считать правильную скорость сближения 'дорого', нужно подумать, не получится ли хуже при такой оценке...
и да, искать пересечение прямоугольников сильно проще чем окружностей или более сложных объектов, т.е. для оптимизации сначала ищем для них (в которые вписаны) а затем уже для тех кто пересекся, считать полностью
ну и конечно классическое разбиение на ячейки, размер подбирать под предельные и средние значения скоростей, можно делить объекты на группы - быстрые и медленные, считать сначала быстрые, в ячейках на его пути и т.п.