Can't test it myself (macOS 10.14.6 Mojave doesn't have that setting), but there are commonly smaller issues on macOS when creating windows outside EventLoop::run (which we should reconsider whether to allow at some point).

Could you try it with the first three windows being created inside Event::NewEvents(StartCause::Init) instead?

I tested this using a custom menubar setup (where the "Merge All Windows" option is available), can reproduce that windows created before EventLoop::run are in some way "separate" from windows created inside.

Odd that it doesn't happen in alacritty though, I think they create the first window outside of EventLoop::run?

Odd that it doesn't happen in alacritty though, I think they create the first window outside of EventLoop::run?

Yeah, that's what I thought too, and it makes me really curious how it doesn't have this issue...

Could you try it with the first three windows being created inside Event::NewEvents(StartCause::Init) instead?

Sure, I'll give it a try soon.

I think they create the first window outside of EventLoop::run?

Yes, we create the first Window before EventLoop::run_return on macOS.

Still no idea why alacritty doesn't suffer from this problem, but I have good news: I just confirmed with the multiwindow example program that the problem goes away if I have it wait and create the initial windows inside of the event_loop.run.

A hunch I had was that the application hadn't entered multithreading mode yet and that's what's causing the differences, but that's not it either...

(Can be checked using [NSThread isMultiThreaded], it changes to true at some point inside -[NSApplication finishLaunching])