When using the above code snipped (making the old one an error) how long will you keep it? - Very long: You still block the macro you wanted to free - Short: Users skipping versions won't notice the change until it's to late. We jumped from 1.55 to 1.67 not so long ago...
We need to stop *defining* non-BOOST_ prefixed macros in Boost. Or injecting anything into the global namespace. Even if we #undef it later. We can however *react* to anything already in the global namespace. It's not us being anti-social, it's us reacting to other code's anti socialness. So, to answer your question, you detect the old setting where the new setting is not applied, and give a useful error (my preference) or warning (Peter's preference).
Is the condition `if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT)` even justified? What if someone else defines BOOST_PHOENIX_LIMIT and my library/app defines PHOENIX_LIMIT? Now I don't get an error and stuff breaks when I don't expect it.
I'd be happy with "#ifdef PHOENIX_LIMIT" then error out personally. Niall