That's the way it was originally. Then the implementation of BOOST_THROW_EXCEPTION got changed creating unexpected behavior and side effects in all the libraries which used. So...
The thought of a new BOOST_HANDLE_EXCEPTION macro named "for historical reasons" pains me. :( Would it not then be a better idea to roll back to the old functionality and have an additional macro (BOOST_THROW_EXTENDED_EXCEPTION?) to provide the extended functionality the current macro provides? This is probably how such a library would have been created if done now and restoring what library authors intended seems like a good idea, plus if new users of the current macro are not happy with it, then I suspect some of those who have had it changed under their feet will be similarly unhappy (though perhaps unaware). I realise that given the macro is used widely through boost, changing it is not something to be done lightly, but since this would effectively be restoring previous functionality I don't see it as such an issue. Additional configuration options to make BOOST_THROW_EXCEPTION == BOOST_THROW_EXTENDED_EXCEPTION and vice versa would allow users to make a decision if the extra information is important to them and allow others to avoid the costs when required (also this would provide complete backwards compatibility with the current setup). Library authors could make an initial call (based on the type of library), users make the final decision. Whatever the final decision, I'd at least like to see the option to make all exceptions of one type or the other. Iain