In no particular order: - There is still the toplevel filesystem.hpp and friends to deal with. You can't move libraries around as a unit (which is the desired capability, right?). - You can't tell what headers don't belong to any 'project'. - It is a lot harder to recursively search for function 'foo' in the headers; you're going to get hits from examples, tests, docs, etc. - It makes it possible to include things you're not supposed to, e.g. private headers from other projects. There is also the potential for name collisions between directories under libs/X and boost/X, You would want some naming convention: boost/ filesystem.hpp filesystem/ O_o/ <---- build/ test/ doc/ or maybe something pythonic like __src__/. - Users expect headers under include/ and source under src/, this will surprise them. - I'm not aware of any prior art. - Will boost.build in fact be able to differentiate between headers, build products, and source files for the sake of installation? - I still like it more than svn:externals -t