Dear David Sankel, Thank you for the review. I fixed up the documentation in the places you requested. (It's on the post-review branch.) I did not use Boost.Test for the reason Zach pointed out: testing infrastructure (and CI, and etc.) was to be ported upon a successful review. The current set up is for ease of use and benchmarking / test deployment outside of the typical boost infrastructure (to allow contributions and reviews to be done easier): it will be replaced with the Boost-based infrastructure later. I turned off the cleverness in both out_ptr and inout_ptr by default. It now takes defines to turn on the aliasing optimization (documented in the post-review branch, here: https://github.com/ThePhD/out_ptr/blob/feature/boost.review/docs/out_ptr/con...). This answers both your and many other's concerns about the aliasing, as well as some of Peter Dimov's specific concerns about how the aliasing is done. I do not believe inout_ptr to be an abstraction so bereft of value: it has already seen successful use and is an important wrapper for many delete-and-allocate/reallocating C APIs, and one of my first users used it for their code. I do not have a design for a new customization point: this is the one I settled on after extensive research into various different areas. I do not think I should change it: but the need for simplicity is important. I could offer a facade to make it easier to implement the boilerplate and avoid concerning a user with storage directly, but struct specialization is still the most flexible and can cover more use cases effectively. Sincerely, JeanHeyd Meneide