It's interesting that you bring up export templates, because that fiasco feature actually already sort of had a reference implementation. The original Cfront compiler actually supported it (admittedly, it was very buggy). The problem with export was that, at the time of discussion (~1996), no one really understood just what the impact of all of the template complexity meant--they assumed that templates were basically just a typesafe variant of the C preprocessor (or at least that most common use could be boiled down to that description; its Turing-completeness was known by then).
So, in that vein, export template was seen as a "well, this is going to be tricky, but so is name resolution in general in C++" and the overarching use case was compelling (you can hide the implementation of a regular function, why not templates?). Compiler vendors objected to the feature, but not on the basis that it was essentially impossible to implement, but rather that major design points would need quibbles. It was eventually accepted into the standard largely with the understanding that everyone would implement something close to it, if not the exact current specification.
The only thing that would have prevented export template from being standardized would have been requiring a fairly robust implementation that could have discovered that export template really did infect every part of the code base in a horrible way, and it should be noted that reference implementations generally aren't that robust. Amaya, after all, didn't prevent HTML 4 or CSS 2 from having unimplementable sections.
Actually I think they kind of did, as Ada already had generics and modules in 1983. And STL was born on Ada.
However, Ada compilers were once upon a time believed to be complexer to implement than C++ ones and had beefy hardware requirements, so maybe they didn't want to try that route.
Now they are trying to finally add modules. :)
Amaya was always in an odd place — it was a "testbed" and not a reference implementation. (Also, if you actually look at the parts HTML 4 that required anyone to do anything, you end up with things like dbaron's table (as in, a desk) implementation of it: put quotations mark at either end of the table, and whatever HTML you put on the table, it has fulfilled all the requirements of the standard.)
But yes, the underlying problem of different approaches is a large part of the reason why you want multiple implementations — the other large part is you want evidence the standard is clear enough to lead to interoperable implementations. These are the two big reasons the W3C now require evidence of two, distinct, interoperable implementations of a specification to proceed down the Recommendation track beyond Candidate Recommendation (i.e., to Proposed Recommendation)… and this is the reason why so much around the W3C takes so long, because people by and large don't want to fix ancient, obscure bugs which are often time-consuming to fix for the sake of the standard progressing.
The situation in C++ is saner, since both GCC and Clang are moving the standard forward, and together make sure that the standard can accept multiple valid implementations and code tends to be truly portable.
The problem is really simply that Microsoft was never interested, at least until very recently, to have a truly standards compliant compiler.
I think Microsoft neglected C++ over .Net before suddenly changing their minds and deciding to support C++ more.
VS2010 was one of the first compilers (even before gcc/clang) to support parts of the preliminary C++0x standard (e.g. lambda functions). But when the final standard was released they fell behind in implementing it.
GCC supported C++0x features back when they thought the standard would be released before 2010. Hence the 0x, not 1x. I remember using the `-std=c++0x` flag back in 2008, when I first took a course on C++, which is a few years before VS2010.