Hi Steve- okay, thanks for clarifying! I think you already know this, but for the general record: the reason for the apparent fixation on this solution is that after a lot of struggle it's emerged as basically the only contender for scipy-development-on-windows; there are a number of problems (fortran, BLAS, C99, python 2.7 support, desire to distribute F/OSS software) and it's the only thing that solves all of them. The details that lead to this conclusion are rather complicated, but here's how I understand the situation as of the end of 2015:

- If you just want to compile C/C++ (don't need fortran or BLAS), and you can either [live with MSVC 2008's somewhat archaic understanding of C] or [drop 2.7 support and only support 3.5], then we're actually in a pretty good place now: you can install the msvc-for-2.7 distribution for 2.7, install msvc 2015 for 3.5, and you're good to go.

- Alternatively if you don't care about your code being F/OSS and have money to spare, then you can solve all of the above problems by using icc/ifort for your compiler and MKL for your BLAS. (The "F/OSS" caveat here is because you actually cannot distribute binaries using this toolchain as F/OSS.)

- If you're a F/OSS project and you need BLAS, then your options are either OpenBLAS or (hopefully soon) BLIS. Neither of them can be compiled with any version of MSVC, because both of them use asm extensions/dialects that MSVC doesn't understand. The good news is that soon probably you will be able to compile them with clang! However, I think clang only targets compatibility with recent MSVC, not MSVC 2008, so this is useless for python 2.7? I could be wrong here.

(Well, you can also try crossing your fingers and try mixing runtimes -- the BLAS interface specifically is narrow enough that you might be able to get away with it. I'm not sure how many projects can get away with just BLAS and no LAPACK, though, and LAPACK is Fortran; I've heard rumors of LAPACK-in-C, but AFAICT they're still just rumors...)

- If you're a free software project who needs [C99 on Python 2.7] or [BLAS on 2.7] or [Fortran, period], then none of the above options help, or show any prospect of helping (except maybe if clang can target MSVC 2008 compatibility). OTOH the mingw-w64-with-improved-MSVC-compatibility approach fixes all of these problems at once, thus eliminating the whole decision tree above in one swoop.

It is true that it doesn't help with the "GPL cooties" problem; AFAIK that's the only limitation. Of course any company has the right to decide that they absolutely will not use a GPL-licensed compiler, for any reason they might feel like. But if they want random volunteers at python.org to care about this then it seems to me that those companies need to *either* articulate some convincing reason why their needs are legitimate (gcc seems to work just fine for tons and tons of companies, including e.g. the entire linux and android ecosystems), *or* start paying those volunteers to care :-). And even if we do care, then I'm not sure what there is to be done about it anyway -- if you want to go buy a license to icc/ifort then you can do that today, have fun, it seems to work great?