Eigentlich ist es doch recht einfach:
man benötigt mehrere Instanzen des Data-Transfer-Objects.
Bisserl suboptimal bezüglich der Performance, würde ich sagen.
Wenn das Datenobjekt ganz genau weiß, wann es nicht mehr benötigt wird, dann lass es sich doch selbst zerstören. Du hast geschrieben, das das Teil sowohl in einem Thread, als auch von außerhalb angefasst wird. Der Thread weiss ja, wann er das Objekt nicht mehr benötigt. Das kann er dann ja auch sagen.
Und wenn Du 'außerhalb' auch weisst, wann Du das Teil nicht mehr benötigst, dann hat jedes Objekt eben einen 'Required'-Zähler (ähnlich dem Referenzzähler), Im Gegensatz zum RefCount zählst Du hier explizit. Das Objekt weiß, das es von zwei Systemen/Threads verwendet wird: Initial ist der Zähler also bei 2.
Wenn der Thread fertig ist, teilt er das dem Objekt mit (RequiredCount --), und wenn der Hauptthread oder wer auch immer fertig ist, macht er das gleiche.
Der Setter vom Zähler ruft Destroy auf, sobald RequiredCount = 0 ist.
Wer das Objekt behalten möchte, meldet dies per 'Require' an, welches einfach den Zähler hochzählt. Wenn man es nicht mehr benötigt, zählt man den Zähler runter.
Das ist ein einfache Regel, die selbst der dümmste Programmierer versteht.
Wobei ich das Interface verwenden würde, weil Grundkenntnisse sollte man dem Anwender schon zumuten
"Hey, ich caste das Interface jetzt mal ganz schnell in die konkrete Klasse und speicher' mir das ganze in einer TList".
Wird man ebensowenig abfangen können, wie "Hey, ich bügle mal 20 Nullen über die Instanz (mit MOVE), mal sehen, was passiert".
Wenn Du mit solchen Vollpfosten rechnen musst, dann bleibt Dir nur ein Manager und statt Objekten arbeitest Du mit einem
Handle.