This is the order in which the engine handles the different steps involved in physics simulations:

1. `PhysicsServer2D.flush_queries`: Calls any callbacks registered by physics nodes on the Physics Server depending on what happened on the previous physics step. This is where collision related signals are fired, and where specific Nodes such as `RigidBody2D` get their state updated after the physics step has run. Apparently you can also register callbacks manually, which are called here.
2. `SceneTree.physics_process`: This is where user code runs, but there's some things that happen before and after. It breaks down like this:
1. `SceneTree.flush_transform_notifications`: Syncs the state of Physics Nodes in the Scene Tree to the Physics Server. Basically, every time you update a Node's Transform, the Node is added to a queue. This method picks up this queue and sends `NOTIFICATION_TRANSFORM_CHANGED` back to each Node. Physics Nodes handle this notification by updating the state of the corresponding physics object in the Physics Server. Calling `force_update_transform` on a Node preemptively fires the notification instead of waiting for this method to be called.
2. `_physics_process` on each Node, and also "internal physics process" (e.g. advance timer nodes).
3. `SceneTree.process_timers`: Advances non-Node timers (ones created directly by calling `get_tree().create_timer()`).
4. `SceneTree.process_tweens`: Steps tweens.
5. `SceneTree.flush_transform_notifications`: Called again so that objects in the Physics Server reflect the state changes applied to the Nodes during `_physics_process` and non-Node timers.
3. `PhysicsServer2D.step`: Performs physics calculations, integrates forces, velocities, determines collisions and enqueues "queries" that will trigger callbacks on the next flush_queries (e.g. `GodotArea2D`, the Physics Server object equivalent of the `Area2D` node, keeps a queue of bodies and areas that entered or exited it since the last flush. This queue is populated during this step).