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. That's just about the worst way to add C++ 11 support. You get problems with ABI conflicts, violation of ODR, and additional bloat.
As an absolute minimum, you need to combine such macros switching std::tuple usage into custom namespace. This prevents collision, violation of ODR, though does little for bloat.
APIBind does exactly the above - custom namespace generation via macro programming, using inline namespaces to make this underlying solution hidden to code using your library.
I think you misunderstood what I meant, the Math exposing tuples in the interface doesn't switch between implementations: rather it's implementation agnostic because it works with the "concept" of a tuple, not a particular implementation. Users will chose which to use based on what they're using elsewhere in their code. None of the issues above apply IMO. John.