The default implementation comes into play in a scenario in which the client has "upgraded" to the new overload, but the (third party - system and generic are already up to date) category hasn't, and I've decided to preserve the message as much as possible rather than to enforce the "no allocation" property at the expense of losing the message. Maybe this is not the correct choice, I'm not sure. But again, this scenario should eventually never occur as third-party categories are updated.
I'm not sure either (so I hope that others chime in with their thoughts -- especially Niall, since he's worked with many of the people who I imagine would have strong opinions one way or the other).
I think Peter's choice is reasonable, given the constraints in play. But I also think the system_error design can only have its rough edges smoothed. It cannot be rescued. Peter disagrees. I've got a fair number of users using the SG14 v2 system_error design at https://github.com/ned14/status-code, some of which informed Peter's improvements of Boost.System. Once they wrap their heads around the weird template inversion, feedback has been universally positive. People just love the arbitrary payload facility, and the way it can be type erased and restored if all the constraints are met. They also like the zero allocation defaults, and not dragging in any heavy STL headers. You must explicitly opt in to allocation, unlike Boost.System. Still, WG21 have not yet judged SG14 v2 system_error. Until they do, we cannot know where it will go. Niall