Strings, bzw. alles an nichtelementaren Typen, übergebe ich sehr gerne über Listen. Dem Thread also in deinem Fall einfach eine TSringList-Property mitgeben, an die der Thread selbst nur anhängt, aber nie selber etwas draus löscht bzw. ändert. Bei einem neuen Eintrag eine Windows-Message an alles was so zu benachrichtigen wäre verschicken, und dort dann lesen und löschen. (Bietet zudem die Option, eine LIFO oder FIFO Queue zu basteln.)
Grad bei Objekten mache ich es zudem ganz gerne so, dass ich zunächst eine lokale Arbeitsinstanz im Thread erstelle, diese komplett vorbereite, und dann das TList.Add() in einer CriticalSection erledige, so dass auch die letzte knall-gefährliche Ecke raus ist, und ich nicht auf die Implementierung von TList angewiesen bin threadsafe Add() zu haben. (Ich hab's aber auch ohne CS noch nie kaputtgehen sehen.)
Hat vor allem den Vorteil, dass ein zeitweise ausgebremster "Abholer" sobald wieder Luft ist alles verpasste in der richtigen Reihenfolge nachholen kann. Ob das wünschenswert ist, oder ob man sowas lieber skipped ist dann wieder vom konkreten Fall anhängig.

Bei der Übergabe zwischen zwei Threads übergehe ich dann noch ganz gern die Messages, und habe im Empfänger-Execute sowas stehen:
Sowas ist im Thread der MainForm eher unpraktisch, daher dahin lieber die Messages.

Einzig unschöne daran ist, dass der Objektersteller nicht der Zerstörer ist, was mindestens einen entsprechenden Kommentar im Code bedarf. Aber ohne GC würden mir da wenige andere gute Wege einfallen, ausser die Gegenrichtung genau so zu gestalten: Nachricht an Thread: "Lösche bitte gleich deinen ersten Listeneintrag." - konsequenter, aber irgendwie auch nicht so wirklich viel schöner.