A header such as boost/libname/foo.hpp is only consistent if libname is monolithic (does not comprise of smaller modules or sub-libraries). IMHO, that is good only for small libraries.
Works for MPL. Nobody ever wonders where to find anything in MPL.
Having just included a bunch of mpl header without looking at the manual once, I agree with that. And no I don't happen to have the names memorized (!), I just thought... "I wonder if the #includes are logical enough that they're called boost/mpl/and.hpp" so I tried it and it all worked first time :-) That said there may be a case to be made for splitting into sub-libraries - we did that with Boost.Math to avoid confusion between a distribution called X and a special function called X. Non-the-less I hope the divisions are obvious enough that most people won't need to look at the manual. So +1 for a mpl/type_traits style of organization from me too, Completely biased yours, John.