Yes, Be GUI is heavily multithreaded, so core dumps were kind of common, and stuff like Swing.invokeLater(closure) only came later in Swing, after existing for a while as community library, after folks having the same issues in Java GUI applications.

Note that on Android they took an hammer solution, programming patters to invoke such code on main thread, have as outcome that there are either lint compile errors, or platform killing the application, for those flows not verifiable at compile time.

IIRC BeOS gave every window its own thread rather than have one GUI thread per app. So in effect every app was multi-threaded by default.

Yes, and it’s been a quarter century or so but this is how I remember BeOS doing it. Every window got a dedicated thread for handling events and GUI updates, and other code would communicate with it via message passing. The OS had a standard message passing system that was pervasive; if I remember right every thread got a mailbox by default.

But it was 90s era C++, so probably that was all just a polite agreement and the reality was that circumventing the message passing to directly call methods on objects that belong to other threads was common, and just as likely to happen by accident as on purpose.