Merci pour votre analyse très documentée.
Réponse courte: non, on ne résout pas les collisions de manière simultanée (ou isométrique comme vous l'écrivez) parce que ça compliquerait trop la résolution des collisions justement.
Réponse longue:
La section 3.1 décompose la mise à jour de la simulation en plusieurs étapes pendant lesquelles on veut s'assurer d'une cohérence minimale. Par exemple la première étape concerne seulement le déplacement de tous les joueurs:
Analyse de la situation relative entre chaque joueur pour déterminer sa cible puis pour définir sa direction de déplacement et déplacer tous les joueurs qui le peuvent vers leur cible. Traitement d’éventuels contacts joueur-joueur
Mais comme écrit plus haut, cela compliquerait le programme de résoudre une mise à jour simultanée ; il suffit d'imaginer plusieurs joueurs qui entrent en collisions pendant la mise à jour... C'est pourquoi la section 3.1 renvoie à la section 3.3 et plus particulièrement à 3.3.2 pour décrire un mécanisme de traitement de collision "asynchrone" où, comme vous l'avez remarqué, l'ordre des joueurs à une importance puisque le résultat est légèrement différent du fait de cet ordre. Nous assumons cette simplification pour que vous perdiez moins de temps dans cette résolution. la méthode décrite en 3.3.2 est très simple à mettre en oeuvre. La revoici:
On procédera comme suit : la possible future position d’un élément mobile est calculée pour DELTA_T et testée vis-à-vis d’éventuelles collisions avec la marge MJ. En cas de collision, la future position n’est pas validée ; l’élément ne bouge pas mais son état peut changer du fait de la détection de collision