Das gibt es nicht und das hat auch seinen Grund: Das for..in verwendet einen Iterator, der explizit oder implizit von der zu iterierenden Menge geliefert wird. Iteratoren stellen ein MoveNext und ein GetCurrent zur Verfügung, das innerhalb der Schleife verwendet wird. Die meisten (wenn nicht sogar alle) Iteratoren verwenden einen internen State um diese Funktionalität zu implementieren. Das ist im einfachsten Fall der Index in einem Array, mit dem das GetCurrent realisiert wird und der beim MoveNext erhöht wird. Die Tatsache, daß man die Gesamtanzahl der Iterationen nicht im Voraus kennt, ist auch nicht gerade hilfreich.
Wollte man diese Iteration nun parallelisieren, würde das mit dieser Form des Iterators natürlich nicht gehen. Man müsste also erstmal eine Reihe von Iterationen (genauer Stride * ThreadCount) ausführen und die jeweiligen GetCurrent-Werte zwischenspeichern. Das kann je nach Anwendungsfall schon mal recht aufwändig werden. Das setzt allerdings voraus, daß sich diese Werte wirklich sauber zwischenspeichern lassen. Eine
Iteration z.B. über ein DataSet, bei dem der aktuelle Datensatz in der Schleife verändert wird, fällt offensichtlich schon mal als Anwendungsfall heraus - von der fehlenden Multithread-Eignung eines TDataSet ganz zu schweigen.
Es ist schon schwierig genug, eine simple Schleife sauber zu parallelisieren. Kommt dann noch eine womöglich unbekannte Implementation eines Iterators dazu, würde ich vermutlich erstmal die Finger davon lassen.