I dont have stability problems with mingw either.
use it all the time, for modeling and rendering.
It is just a problem with too long path names while compiling. The MinGW buildbot needs shorter directory paths that’s all! Unfortunately nobody listens 
I even offered to set up another MinGW64 buildbot as failover but that too wasn’t heard. I think we’ll just have to wait for the 2.68 release, there too much to do and not enough time right now!
Hi, just dropped by to offer my 2c.
First of all, build failure on scons in big path lengths is because of scons, not mingw.
Second, the instability is due to the MinGW64 crappy pthread implementation. I tried using pthread-win32 which is better (regular MinGW uses it and it can use openmp) yesterday but it crashes on startup. There are two things to try here, either fix the pthread implementation of MinGW64 and provide them with a patch or recompile everything using the pthread-win32 library (I only compiled blender with it) and pray it works. I have given a few afternoons to the first problem without success so far.
I am really OK with dropping MinGW64 for various reasons.
- The pthread problems have been mentioned often in their mailing list (I even provided them with a file that reproduces a hang with openmp) and no solution has yet been reached and it’s about half a year if not more already.
- Looks like performance difference is not that great anymore
- both MinGWs actually require presence of the microsoft developer tools to work with debug builds and build CUDA kernels, which sort of defeats the whole purpose.
Maybe we should give it a thought indeed.
Please don’t drop MinGW64 as it’s the only way I see having a 64bit one click 100% free build solution on Win 64bit. 
(I don’t care about the build bots, just saying on SVN / libs / dlls.)
I don’t think MinGW will be dropped. But the focus lies on production compilers atm. We want a good 2.68 release 