But I don't really want to enter these implementations in Boost instead of yours. Your implementation has been tested in practice and is more feature-rich. The error_code_extended infrastructure adds significant value, and if you agree to a larger (or customizable at runtime) ring buffer and chaining support, they'll become even better. (Attaching information to an error code is a very good idea of yours.)
In short, I'd rather see your implementations in Boost, but with something close to the interface I present - if the community can agree on it, of course.
A shame. I already invested six months of effort taking a mature library and getting it ready for review. I had been hoping to avoid more work on this, AFIO languishes until Outcome is done. Still that said, if Outcome changes significantly, better it happens now before more AFIO code is hard wired around Outcome. Some of the AFIO filesystem algorithms are quite subtle and rely very heavily on Outcome behaving exactly just so. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/