What if the default config of the other library is not suitable? The reason why I added config enforcement is because compiler-based TLS can prevent using Boost.Log in dynamically loaded (i.e. with dlopen()) libraries. So with default config Boost.Log binaries are inconsistent and not working in some cases.
In my opinion, this is up to the user of the library to decide. Duplicating the implementation of an entire library to work around different configs is one reason some libraries get a bad reputation, please don't do it. Instead, the user should configure the libraries as appropriate to match the features they need. If the user needs to use Boost.Log in shared objects and ASIO is not able to do that by default, then that is opt-in and, in my opinion, should be explicit to ensure they link against an appropriate ASIO. It seems to me that Log depends on ASIO so therefore Log needs to respect the ASIO default by detecting BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION and setting any internal flags appropriately. -- chris