From reading the mingw-w64 bug list, and some recollection, there are issues with handling cleanup of C++ objects and with multithreading. The latter is especially problematic with complex code bases. This doesn't mean that these bugs are the issue with gzdoom/mingw64, but it seems difficult to eliminate as the cause, especially since there were extensive efforts to fix these issues.
One test is to obtain debug C++/threading runtimes and link gzdoom to those. Apparently, the C++11 threading in mingw-w64 is implemented by mapping to the win32 threading api and supplementing that with their own mingw-w64 functions. Since gzdoom works in linux/gcc, it does suggest problems in mingw-w64. I would start documenting more specific causes of these bugs and post the findings on their boards.
I would work on the XP version of 32-bit gzdoom/mgw64 first. The next priority seems to workaround the crash bugs (wait until mingw-w64 fixes the C++11 threading if necessary) and make a working openal library. The openal problem should be trivial. Post any issues and I'm sure you will have good replies since it is widely used and simple to make reversions to its code base.
The sjlj and dwarf versions, from what I recall, is for exception handling. Possibly dwarf is better for the mingw32 version, but it is reasonable to test the dwarf version once to see if the crash on exit bug exists (this can be done last, I would think).