Принципно, поне според документацията нито action-ите се палят,
нито thread-ите, още по-малко пък event-ите.

"- по принцип onExecute() на даден action пали ли друг thread или се изпълнява в main-threada ?"

Action-ите са си нормални процедури, които в общия случай (случая, в който не ги "извикваш" директно от друго място в кода) се държат като стандартни message-handlers на WM_COMMAND. Така, че те в никакъв случай не създават допълнителни нишки и се изпълняват в контекста на извикващото разклонение, обикновено main.

"- какво става ако се изпълнява даден код в main-threada и докато се изпълнява се пали някакъв
друг action ?"

Генерира се съобщението WM_COMMAND, изпраща се през SendMessage и го прихваща WindowProc на джама. Ако процедурата "намери" необходимия и handler (action) го изпълнява, пак в контеста на main. Ако не го намери го подава на DefWindowProc или връща стойност различна от нула.

"и изобщо по принцип като се изпълни някакв action или се запали някакъв event къде се "вмъква" изпълнението им ако са в main-threada ?

Ако имам един метод, който се изпълнява сравнително дълго време.
и докато той се изпълнява се пали някакъв event или някой action от UI-то
тогава къде ще се "впише" изпълнението на този event или action ?
ще се изпълни ли метода докрай преди да се предаде управлението на event-a / action-a ?"

Както ти написах по-горе сендва се WM_COMMAND. Ако през това време ти си в "дългия" метод и в тоя метод никъде не проверяваш опашката за новопостъпили съобщения - GetMessage, PeekMessage,
MsgWaitForMultipleObjects, (за Делфи - Application.ProcessMessages) джама ти спира да кореспондира. Т.е. action-а, който би трябвало да се изпълни ще чака да "излезеш" от дългия или от веригата дълги методи. Това, разбира се в случай, че веригата е контекста на главния.

Доколкото разбрах ти си изнесъл тая верига в отделна нишка, в такъв случай трябва да помислиш върху синхронизацията между двете - първо главния да разбере къде в момента е вторичния и вторичния да знае дали да спре и да почне от ново. За едното може да ползваш една елементарна LONG-променлива (LongInt) преди да пуснеш вторичната нишка = 0,
после преди(след) всяка операция - InterlockedIncrement()/Inc()/.

Не лоша идея е да набуташ action-ите в един масив и тоя LONG да ти се явява индекс на следващото за изпълнение действие. Ако индекса случайно стане -1 /InterlockedExchange/ туй ще рече че трябва да спреш.

За второто - много е важно какви операции ще извършва second-thread-а, най-вече какви ресурси ще заделя - например памет. Вариантите ти са поне два:

а) на всеки няколко реда в "дългите" методи да проверяваш нещо от сорта
на BOOL bRestartNeeded за TRUE, може и направо if (Terminated) ако ще създаваш нишката всеки път и да прекратяваш, сигнализирайки някакво събитие. Може WaitForSingleObject( MyThread.Handle, INFINITE ), но при всички случаи приложението ти ще hung-ва. Е, може да врътнеш един цикъл:

MyThread->Terminate();

while ( WAIT_TIMEOUT == WaitForSingleObject( (HANDLE)MyThread.Handle, 50 /*0*/ )
{
Application->ProcessMessages();
}

като не забравиш да "заключиш" влизането тука.

б) другия вариант - без чакане, е цялата памет и ресурс необходими за функционирането на вторичното разклонение да ги заделиш още в main, преди да го създадеш. И като ти възникне user-event дето трябва да рестартира веригата:

SuspendThread( (HANDLE)MyThread.Handle );
TerminateThread( (HANDLE)MyThread.Handle, 0 );
FreeThreadRequiredResources();

DoThisUserAction();

// Ако приемем, че на OnTimer ще създаваш нишката наново.
Timer->Enabled = true;

Надявам се да съм бил полезен.