A myriad of libboost errors caused in tf or ros::param::get due to std::tuple declaration? Fix -std=c++11??

edit

Ubuntu 16.04 ROS Kinetic DPKG states libboost1.58 for all libraries, catkin_make states libboost 1.50

Very recently I decided to clear /build and /devel and rebuild my workspace. A large list of boost errors for almost every package came out.

I see these errors start in multiple ros binaries:

ros::param::get <-  tf/listener.h <- tf.h <- boost/tuple.hpp 
tf/transform_broadcaster.h <- tf.h <- boost/signals2.hpp <- c++/5/tuple

Some of the error descriptions are included below:

from /usr/include/c++/5/tuple:35:0,
             from /usr/local/include/boost/signals2/detail/variadic_slot_invoker.hpp ... error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or enter code here-std=gnu++11 compiler options.

from /usr/local/include/boost/signals2/variadic_signal.hpp:21:0,
                 from /usr/local/include/boost/signals2/signal.hpp:38 ... /usr/local/include/boost/signals2/detail/variadic_slot_invoker.hpp:68:41: error: ‘std::tuple’ has not been declared
           R operator()(Func &func, std::tuple<Args...> args) const

And

 /usr/local/include/boost/signals2/detail/variadic_slot_invoker.hpp: In member function ‘R boost::signals2::detail::call_with_tuple_args<R>::m_invoke(T*, Func&, boost::signals2::detail::unsigned_meta_array<indices ...>, int) const’:
    /usr/local/include/boost/signals2/detail/variadic_slot_invoker.hpp:78:23: error: ‘get’ is not a member of ‘std’
               return func(std::get<indices>(args)...);

OR

from /usr/local/include/boost/signals2/detail/variadic_slot_invoker.hpp:22...
error: ‘std::tuple’ has not been declared
           R operator()(Func &func, std::tuple<Args...> args) const

I believe the error might be related to the condition described below:

The C++ standard doesn't allow a user to add forward declarations or definitions into namespace std. Adding declarations or definitions to namespace std or to a namespace within namespace std now results in undefined behavior.

At some time in the future, Microsoft will move the location where some STL types are defined. When this happens, it will break existing code that adds forward declarations to namespace std. A new warning, C4643, helps identify such source issues. The warning is enabled in /default mode and is off by default. It will impact programs that are compiled with /Wall or /WX

People have suggested adding the following compile options to a package's CMakeLists.txt:

add_compile_options(-std=c++11)

And

set(CMAKE_CXX_FLAGS "-std=c++11 ${CMAKE_CXX_FLAGS}")

This solution seems only partial. Some packages display other libboost errors after this. Even if it were to work, it seems undesirable, as I would have to add this flag across hundreds of packages.

Are others experiencing these problems? Did this result from changes to C? A new standard? Any good solutions?