I can see why you might think that organisation superior, and I did start out with that design. In fact, boost-lite used to define the exact same macros as Boost, precisely because of that organisation, the idea was that boost-lite was a substitute for Boost.
The standalone Outcome does not have to use its own namespace. It could retain the boost::outcome namespace. That way we can remove yet another dependency (the part of "boost-lite" previously known as APIBind.)
If Outcome is accepted in std-flavoured form, I already intend to delete the namespace bindings code entirely. They have only hung around due to this upcoming review.
That gives us a clean separation where the Boost.Outcome repository is "untainted" by any foreign submodules, and the standalone Outcome repository is a Boost.Outcome without a Boost dependency.
There is no "taint" from the boost-lite submodule. It can be included into any translation unit without ill effect. It is a good neighbour to all other C++, including different versions of itself. You may find a reply to Robert sent recently with a description of one post-approval Boost integration strategy I might take (use boost-lite submodule if checked out, else fall back onto hard Boost dependency). But I consider all that process and packaging trivia. None of it is hard. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/