There's been a long standing "issue" with how the b2 configure checks work. Or rather how some times they don't work. In particular the issue is that the set of properties considered relevant for the configuration checks was fixed. As of last night that is now resolved <https://github.com/boostorg/build/commit/450c25c3b52f5ddcb323140f8423adf3b85b6b1a>.

As the commit mentions the set is no longer fixed and is configurable by users. The changes now mean that:

1. Any subfeatures of the top level relevant feature set are also considered as part of the set. This means that one can a configuration like below to support multiple invocations of the same toolset with different options. In particular the STD options:

=== user-config.jam ===

import feature ;

using clang ;

feature.subfeature toolset clang : std : cxx03 cxx11 cxx14 cxx17 : optional composite propagated ;

feature.compose <toolset-clang:std>cxx03 : <cxxflags>-std=c++03 ;

feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ;

feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ;

===

And one can then invoke "b2 toolset=clang-cxx14,clang-cxx11" and get non-colliding configuration checks.

2. The set of relevant features is now soft wired as the set of subfeatures of the "<composite>" feature. Which means ones can add to the default set <https://github.com/boostorg/build/blob/develop/src/build/configure.jam#L26>. For example to add threading choice to the relevant features:

=== user-config.jam ===

import feature ;

import configure ;

feature.compose <configure> : <threading> ;

===