Naja, das geht, sofern der Compiler sowas unterstützt. Eine "Gabelung" in der Ausführung, wie du's vorschlägst ist ohne Hilfe des Compilers wohl nicht ohne eine Auslagerung von Code in eine separate Methode möglich (dich könnte
diese Library interessieren) - es sei denn man macht zur Laufzeit eine Code-Analyse oder so...
Das "FiberThreading" umgeht das Problem, das man normalerweise beim Threading ohne anonyme Methoden hat. Und zwar, dass man den Code jeweils in mehrere Stücke unterteilen muss.
Ein (initialer) Wechsel von MainThread in einen Thread ist damit verbunden, eine TThread Instanz zu erzeugen und die Parameter z.B. über den Konstruktor/Properties zu übergeben. Die Rückgabewerte vom Thread muss man ebenfalls über Properties regeln. Dann hat man allenfalls mehrere Synchronize-Sections. Einzeln als Methoden ohne Parameter versteht sich. D.h. Die Kommunikation geschieht hier über irgendwelche privaten Klassenfelder oder so. Alles in allem bedeutet das ne Menge Codefragmente und ne Menge temporäre Klassen-Felder! Geht schon, aber man überlegt sich dann zweimal, ob man Code wirklich in einen Thread auslagern will, oder ob man es doch sein lässt und sich mit Application.ProcessMessages zufrieden gibt.
Ausserdem sind mit FiberThreading Sachen möglich, die bisher in dieser Form gar nicht möglich waren. Das zeigt im Beispielprojekt der letzte Test. Dort wird inmitten einer for-Schleife entschieden, dass der Rest in einem Thread fortgeführt werden soll und den MainThread nicht mehr blockieren soll.
Mir ist bewusst, dass man sowas nicht täglich braucht. Die Unit ist auch eher aus einer Spielerei mit Fibers entstanden und es ging erst mal darum zu zeigen, dass sowas grundsätzlich geht.