When TIdNotify.Notify() is invoked by code in the main UI thread, it now respects the TIdNotify.MainThreadUsesNotify property again.
Many years ago (prior to mid-2010), whenever TIdNotify.Notify() was invoked by code in the main UI thread, if the TIdNotify.MainThreadUsesNotify property was True then Notify() would use an internal worker thread to queue the notification for delayed execution using TThread.Synchronize(). That delay functionality was lost (but not the property itself) when Notify() was updated to stop using the worker thread and instead use TThread.Queue() in Delphi/C++Builder 8+. When TThread.Queue() is called in the main thread, it executes the specified method immediately, it queues the method only when called in a worker thread.
Fast forward to RAD Studio 10.2 Tokyo, which as added a new TThread.ForceQueue() method for RSP-15427, allowing code in the main UI thread to queue a specified method for delayed execution.
TIdNotify.Notify() has been updated to once again queue notifications for delayed execution when invoked by code in the main UI thread and the MainThreadUsesNotify property is True. An optional AForceQueue parameter has also been added to the TIdNotify.NotifyMethod() method.
Using TThread.ForceQueue() when available, TIdNotify.Notify() can delay execution without having to use an internal worker thread at all. For Delphi/C++Builder 10.1 Berlin and earlier, and FreePascal, the worker thread will still be used, and it has been updated to use TThread.Queue() when available instead of using TThread.Synchronize().
TIdNotify has also been updated to now support TThread.Queue() in FreePascal 3.0 and later.