I understood that GCC is falling out of favour because the people maintaining it have become somewhat arrogant, and now that LLVM is here (and is very good) people are voting with the feet.

Slashdot had a discussion about LLVM’s new support for C++11. _merlin says:

Oh I don’t think anyone thinks it’s evil, just that it’s pure
self-interest rather than generosity. GCC’s phenomenal popularity has
led to its maintainers growing massive egos and behaving like total
[****]. Bugs are introduced faster than Red Hat and Apple can get
patches for them accepted, and they have a nasty habit of not looking
at bug reports, then closing them due to inactivity without actually
fixing them

which chimes in with your observation about the 4-year delay.

GCC’s popularity and usability is not questionable.

• GCC is still great compiler and most widely used.
• GCC supports languages that clang does not aim to, such as Java, Ada,
  FORTRAN, etc.
• GCC supports more targets than LLVM.
• GCC is supporting C++11

From
https://stackoverflow.com/questions/12210102/does-gcc-4-7-1-support-threads
mingw build at http://code.google.com/p/mingw-builds/downloads/list
supports threads.

But important consideration is License.

• GCC is licensed under the GPL license. clang uses a BSD license, which allows it to be embedded in software that is not GPL-licensed.
• The primary reason for switching from GCC to Clang is the incompatibility of GCC’s GPL v3 license with the goals of the FreeBSD project.

FreeBSD has an uneasy relationship with the GPL. BSD-license advocates
believe that truly free software has no usage restrictions. GPL
advocates believe that restrictions are necessary in order to protect
software freedom, and specifically that the ability to create non-free
software from free software is an unjust form of power rather than a
freedom. The FreeBSD project, where possible, tries to avoid the use
of the GPL (For details
https://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang-llvm)

Other important Considerations

From http://clang.llvm.org/comparison.html#gcc

• The Clang ASTs and design are intended to be easily understandable by
  anyone who is familiar with the languages involved and who has a
  basic understanding of how a compiler works. GCC has a very old
  codebase which presents a steep learning curve to new developers.
• Clang is designed as an API from its inception, allowing it to be
  reused by source analysis tools, refactoring, IDEs (etc) as well as
  for code generation. GCC is built as a monolithic static compiler,
  which makes it extremely difficult to use as an API and integrate
  into other tools. Further, its historic design and current policy
  makes it difficult to decouple the front-end from the rest of the
  compiler.
• Various GCC design decisions make it very difficult to reuse: its
  build system is difficult to modify, you can’t link multiple targets
  into one binary, you can’t link multiple front-ends into one binary,
  it uses a custom garbage collector, uses global variables
  extensively, is not reentrant or multi-threadable, etc. Clang has
  none of these problems.
• For every token, clang tracks information about where it was written
  and where it was ultimately expanded into if it was involved in a
  macro. GCC does not track information about macro instantiations when
  parsing source code. This makes it very difficult for source
  rewriting tools (e.g. for refactoring) to work in the presence of
  (even simple) macros.
• Clang does not implicitly simplify code as it parses it like GCC
  does. Doing so causes many problems for source analysis tools: as one
  simple example, if you write “x-x” in your source code, the GCC AST
  will contain “0”, with no mention of ‘x’. This is extremely bad for a
  refactoring tool that wants to rename ‘x’.
• Clang can serialize its AST out to disk and read it back into another
  program, which is useful for whole program analysis. GCC does not
  have this. GCC’s PCH mechanism (which is just a dump of the compiler
  memory image) is related, but is architecturally only able to read
  the dump back into the exact same executable as the one that produced
  it (it is not a structured format).
• Clang is much faster and uses far less memory than GCC.
• Clang aims to provide extremely clear and concise diagnostics (error
  and warning messages), and includes support for expressive
  diagnostics. GCC’s warnings are sometimes acceptable, but are often
  confusing and it does not support expressive diagnostics. Clang also
  preserves typedefs in diagnostics consistently, showing macro
  expansions and many other features.
• Clang inherits a number of features from its use of LLVM as a
  backend, including support for a bytecode representation for
  intermediate code, pluggable optimizers, link-time optimization
  support, Just-In-Time compilation, ability to link in multiple code
  generators, etc.
• Clang’s support for C++ is more compliant than GCC’s in many ways
  (e.g. conformant two phase name lookup).

From
http://www.linuxquestions.org/questions/slackware-14/gcc-vs-llvm-931034/

• The advantage of llvm/clang is its modular design, so it can be
  interfaced and used for example to create static code analysis tools,
  what becomes more and more important ()

From http://clang.debian.net/

• clang is now ready to build software for production (either for C,
  C++ or Objective-C). This compiler is providing many more warnings
  and interesting errors than the gcc suite while not carrying the same
  legacy as gcc.

The reason why it takes a lot of time is because it takes a lot of work to get a solid foundation to build the headers on top of. The way mingw-w64 seems to bo is to build a solid pthreads-like library on Windows. There’s less upstream grumpiness over that than introducing a dependency on the native threading of the Windows API.

mingw-w64 implements <thread> and the other C++11 headers on top of their own winpthreads library. This should be available for testing in both Mingw-builds and rubenvb’s distributions of the mingw-w64 toolchain. I would recommend following the mingw-w64 mailing lists if you want to track where most of the work on native Windows GCC work is done.

The Qt Project has a wiki page detailing their current recommendation and an over view of GCC toolchains on windows, see this Qt Project wiki page.