This isn't the claim.
Well that's certainly how it read to me, in fact it seemed to me that you were originally advocating "lets throw everything away and start again".
The claim is that so long as the libraries in Boost which depend on STL11 equivalents cannot use the STL11 equivalent, they are suffering from at least these problems:
1. An inability to easily interoperate with code which uses the STL11 primitives e.g. std::future. Yes that can be an issue, but it's easily addressed via Boost.Config #ifdef's.
Some time back I changed Math to use std::tuple internally when available, now we're starting the process of exposing that to end users so they can use *any* suitable tuple type (including the 2 different versions in Boost, plus tr1 and std versions). The code doesn't care which, that's what generic code is for ;) For sure adding C++ support to older libraries may sometimes seem slow - but it's demand driven - unless there's a really good case for changing things lib authors are understandably cautious (and don't even get me started on noexcept specifiers!!) Basically if it's working perfectly well now, there has to be a good reason for major architectural changes, and those have to be handled on a case by case basis.
2. A compile time and binary bloat deficiency, sometimes very substantial. Really? Why would the Boost versions be so much larger than the std versions? Can you give an example? 3. A lack of sufficient maintenance, else the maintainer would have made use of STL11 available already just as Chris did with ASIO.
4. A potential deficiency in reliability and quality, as the STL11 Boost equivalents are probably not as well tested, audited, and maintained as the STL11 editions simply due to resources invested. I disagree strongly, often the Boost versions are mature, portable, heavily tested and in widespread use. IMO we haven't even begun to shake out all the bugs in the some of the std versions yet.
Do you realise that GCC completed it's C++11 support only in the most recent 5.1 release? Or that <regex> was a non-functioning stub until 4.9? And I haven't even even mentioned Boost-specific extensions - if you need full Perl compatibility then it's pcre or Boost.Regex, std::regex doesn't get there for example. John.