Real-world software projects don't always get to use the latest stuff in a timely manner. I'm working on some code that needs to work across several platforms, which generally means programming to the least-common-denominator. What I want to bring up in particular is the issue that the compiler may be more up to date with C++11 than the libraries. Someone trying to use Boost on Android (IIRC) trying to change the Boost config to tell it that C++11 support is available said it was like playing "Whack-a-Mole", in that each change caused more problems elsewhere. It seems that the overall issue is Compiler vs Library. Saying that rvalue references are available doesn't mean that std::move, std::forward, etc. are available. I threw together a move.h file that contains forward, move, and a few others taken exactly from the standard — all one-liners. That lets people who know that the compiler really does know what to do with && write code that uses them, just so long as they remember to use the project's namespace and not std, or the multi-platform build coughs it back out. I also successfully crossbred the unique_ptr implementation from libcxx-3.4 with Boost + my own move.h namespace. Now try putting a (real) move-only object into a boost::container::vector when Boost is built with BOOST_NO_RVALUE_REFERENCES. Might I convince the powers-that-be to reconfigure Boost with that #define removed? That could be done when upgrading Boost anyway, but it seems to not work! Whack-a-mole. I didn't do it personally, but it appears that at the very least Boost would need its own move.h and whatever odds and ends it assumes are present. That would be quite easy since these little functions are just fancy casts and you can mix code that calls different "implementations" of them. So Boost could always use boost::move which turns into static_cast<typename boost::remove_reference<T>::type&&>(t); (as opposed to just 'using' the std::move) and other code doesn't care. That is, it would not be necessary to configure "has std::move vs not have std::move" but just don't rely on std::move at all. In short, I don't know if it's just me, but most of the company jobs I've worked have lagged behind, with upgrading the compiler and/or libs being a Big Deal, especially if using outside code that's already compiled. So, I want to raise the possibility that making Boost work with native rvalue references but legacy (C++03) standard library would be useful to some significant population of developers. #undef'ing BOOST_NO_RVALUE_REFERENCES in the config ought to just work, at least on a lib by lib basis. I mean, it might be fine if some libs didn't handle that as many people don't use every single lib in every project. Boost.Container is interesting though because it is used to overcome legacy std::map etc. as one of its stated goals. It's also good for avoiding platform compatibility issues when all platforms use the same map class (e.g. the master build doesn't spit out failures as erase is void on some platform but returned an iterator on the platform used to try the code before checking it in). The current version of Clang as used for Mac and iPhone/iPad development has && working even if you don't enable the C++11 dialect. So sneaking in some &&'s in a program doesn't require any reconfiguration of the projects. —John