Eine for..in Schleife ist per Definition dafür gedacht, dass man die Elemente in einer beliebigen Reihenfolge durchläuft. Dass sie aufgrund der aktuellen Implementierung eine bestimmte Reihenfolge haben, mag sein, ist aber nicht garantiert.
Deshalb:
Wenn die Reihenfolge wichtig ist, niemals for..in nutzen. Theoretisch kann man das zwar mit einem eigenen Enumerator sicherstellen, aber das ist nicht gerade sauber...
Besser ist es über den Index und for..downto zu gehen und den aktuellen Eintrag selbst ggf. in eine Variable zu speichern um ihn nicht immer wieder aus der Liste abrufen zu müssen.
Wobei die FOR-IN-Schleife selber nichts mit der Reihenfolge zu tun hat.
Sie läuft einfach nur von vorhne nach hinten alle einträge durch, bis der Enumerator sagt, daß es nichts mehr gibt.
Die Reihenfolge der Daten vom Enumerator sind nicht vorgeschrieben, womit es also kein Problem ist, wenn man sich einen Enumerator erstellt, welcher die Daten in umgekehrter Reihenfolge liefert.
Das ist nicht ganz korrekt. Für einen Menge Elemente, die einen Index Zugriff bieten, liefert auch ein for-in die Elemente in der gleichen Reihenfolge zurück wie mit einem for-to (nicht for-downto!). Durch die Möglichkeit, selber den Enumerator für eine for-in Schleife zu schreiben, verbietet natürlich keiner, die Elemente in einer komplett anderen Reihenfolge (oder sogar non deterministisch) zurückzuliefern (was aber
imho schon an Sabotage grenzt).