Some good news, sort of: using almost identical code it doesn’t happen in my minimal test app. So it seems to be something specific to the app that loads the bundle, which probably means I can find out what the problem is and fix it.
Also, this should mean that nothing’s wrong in JUCE 
The crash of the (empty) NSView descendant has gone away now that I’ve removed the autorelease pool from the application’s main function (in juce_application.cpp), for what it’s worth.
On to defining my own component peer…
In fact, if I define JUCE_AUTORELEASEPOOL as empty, I get no crash at all with my own component peer (not yet fully implemented, though), while I do get a crash with Juce’s one. More news to follow, I’m sure.
Well, in the end I gave up trying to find the real cause. There was definitely a problem releasing NSView or NSWindow objects, but I managed to get it to work. First of all by running the window modally (though that didn’t work when I tried it initially) for one occurrence of the crash and then by reacting to the systemRequestedQuit() function in a different way.
I still wonder what happened but after more than two weeks it’s time to finish this.
