But I don't understand why you are against it. After all, there is BOOST_CXX14_CONSTEXPR (BOOST_CXX17/20_CONSTEXPR are still missing - but I already offered that). So we have an expressive scheme BOOST_CXXnn_CONSTEXPR that is unambiguous and readable.
C++14 lifted some major constraints on what can be in a constexpr function compared to C++11. Most notably support for more than just a return statement. Being able to differentiate that is useful in practice.
For example, std::round in C++23 is constexpr
The CXXyy part in the Boost.Config macros refers to the language level support. While std::round is at library level. So a compiler supporting C++14 constexpr syntax might not have a std library where std::round is constexpr even if it claims C++23 support. So the better way here would be a more focused macro combining the language level of the constexpr feature and the library support of what that specific function is using. Hence a possible BOOST_CXX23_CONSTEXPR is misleading: It doesn't refer to the language level anymore. And if you bind that to availability of constexpr std::round the next user may want to use it with another std:: function which is supposed to be constexpr in C++23 but due to a std library defect is not yet. Hence the distinction between library level and language level feature macros. However IIRC some C++ standard added support of (temporary) allocations in constexpr functions. That would be worth a dedicated feature macro as that change fits the idea described above. I hope that helps, Alex