Doesnt look like it, i commented out the message handler, but still does it …still keeping at it … wont give up 
So … by removing the corefoundation call
for (FCocoaWindow* Window : WindowsToClose)
{
// issue close to CoreFoudation
//[Window close];
// clear memory
[Window release];
}
it seems to not happen… it feels wrong though … 
cause then any delegates assigned wont get a callback from CF
The thing is that the Editor behaves irrational. It can hag every few clicks for hours and suddenly work without problem for hours, with the same apps open in the background. Somewhere the Editor makes a bad call and it hangs.
This is a call that happens quite frequently, and happens outside of most other events.
By commenting out the disposing of the windows it hasnt had a problem 
But then again, its not properly telling anything tied to the window that it is closing, so I’m looking at that now, and tonight. We’re getting there…
The Editor has various issues with its windows. Either they flicker when you move them between screens/monitors, lose the pointer tracking, minimize but leave a ghost window lingering.
After an exhaustive day looking at everything inside the box for macOSX/CoreFoundation support, and a bunch of different fixes, the simplest seems to be the top (one I’ll send a PR in for).
Because closing windows is already deferred, there seems to be a race condition between two threads when a window is closed. To counter this we simply say when its time to run the close call it isn’t put off any longer (already is deferred a cycle).
Engine/Source/Runtime/Core/Private/Mac/MacApplication.cpp:1678 ( 4.18 code base )
Nicely done, let’s hope this is the source of the problem.