Hi!
RewriteRule .* index.php
Die zweite missfällt mir, weil dann auch example.test/img/image.jpg auf /index.php weitergeleitet wird. Und selbst wenn ich mit einer RewriteCond prüfe, ob eine existierende Datei oder ein Verzeichnis angefordert wird, so entstehen immer noch Probleme, wenn versehentlich mal eine Seite "img" angelegt und example.test/img angefordert wird - da unklar ist, ob example.test/img ein Verzeichnis oder eine Unterseite ist.
Deshalb meine Vorliebe für "verunreinigte" Clean URIs. Wenn ich festlege "alle meine Mehr-Oder-Weniger-Clean-URIs beginnen mit page/" und "page/ darf kein physikalisches Verzeichnis sein, zumindest keines, das per HTTP erreichbar sein muss", kann ich bedenkenlos alles, was ^page/.*$ matcht auf /index.php weiterleiten.
Du willst also Probleme, die durch Unachtsamkeit beim Benennen von Verzeichnissen, die sich dann mit verwendeten URLs beißen, entstehen, lösen. (Schön geschachtelt, nur leider ein bisschen kurz.) Dabei nimmst du einen Lösungsansatz, der per se nicht besonders schön ist und gerätst dabei in weitere Probleme, die sich gar nicht bis nur unschön lösen lassen. Ich würde ja die ganzen dabei entstehenden Komplex- und Kompliziertheiten auflösen, indem ich die bewährte -d/-f/.*-Lösung nähme und bei der Benennung von Verzeichnissen aufpasste. Dein img-Verzeichnis für die statischen Bilder der Seite müsste nicht so prägnant und kurz benannt sein. Das kann ruhig etwas komplexer und mit weniger "Könnte-später-mal-verwendet-werden-müssen"-Gefahr benannt sein. Nenn das doch einfach /page/img/ (und /page/css/ etc.), dann ist es aus dem Weg. Wie die URLs zu eingebetteten Ressourcen aussehen, interessiert doch im Grunde niemanden. Und eine URL /page als eine Seite deiner Anwendung im Namen wird's wohl nicht geben.
Lo!