Wie Dejan Vu schon korrekt angemerkt hat liegt der größte Fehler in der Sichtweise beim Arbeiten mit Threads.

Ein Thread ist ein Ausführungs-Kontext. Punkt - mehr nicht!

So ein Thread kann eine Aufgabe (Task) ausführen, damit der Hauptthread (aha, noch ein Thread) dadurch nicht belastet wird, denn die Aufgabe des Hauptthreads besteht in der Kommunikation mit dem Anwender.

Vergleichen kann man das mit einem Unternehmen. Da gibt es die Mitarbeiter (Threads) und die erledigen Aufgaben (Tasks). Was mich interessiert ist nicht ob ein Mitarbeiter aufhört (ich bin nicht vom Personalwesen), sondern ob die Aufgabe erledigt wurde.

Das Konstrukt aus dem Ausgangspost könnte man wie folgt darstellen:
Ich stelle einen Mitarbeiter für genau eine Aufgabe ein und wenn der diese Aufgabe erledigt hat, dann kann er sich wieder schleichen (FreeOnTerminate) So, den Erwin habe ich dafür gewonnen und der geht auch fröhlich an sein Werk. Nach einer gewissen Zeit rufe ich dann Erwin .... aber da kommt keine Antwort. Der Erwin ist einfach schon nach Hause gegangen.

In Delphi XE7 ist das jetzt (endlich aber noch nicht abschließend) integriert. Da gibt es ThreadPools (die Personalabteilung) und Tasks (Aufgaben). Man erstellt einfach nur noch Aufgaben (Tasks) und die Personalabteilung (ThreadPool) kümmert sich darum, dass genügend Mitarbeiter (Threads) vorhanden sind abhängig von den verfügbaren Ressourcen (Auslastung der CPU).