Joel de Guzman wrote: For non-core libraries, it is always better
to use boost/<library>/detail and boost::<library>::detail as many libraries are already doing. If they need to be used by other libraries, then my thinking is that they ought not to be in detail, but rather, hosted by a parent library, just like that suggested in the last item in the list of current "practices". Then, the natural place for its documentation is the host library (e.g. The proto docs are currently in xpressive, the pre-review of fusion was once in spirit).
The case of codecvt_utf8 is interesting in his regard. In the course of development, we ended up with one copy in the serialization library and another identical copy in the program options library. Strenuous objections were raised about this. So it was "moved" to boost/detail - only because of these objections. It was never reviewed as a separate entity. It had its own tests and documentation page - but there was no place to put this in boost/detail. Perhaps boost/utility would be better - but then it would have had to suffer a review and no one wanted to take ownership. And recently I discovered that I forgot to take it out of the serialization library in any case. So a strict adherence to the proposed policy will result in duplicated code - not the end of the world - but some are going to object to that. As an aside, I noticed a talk titled something like "hidden boost gems" where codecvt_utf8 was specifically mentioned. So some things end up being quasi-official by default. Robert Ramey