Do we even want the third variant? That is, do we want to support tr2::optional of something that is neither copyable nor movable? My gut instinct says no, that's unintuitive.

boost::optional can be used for many purposes. One of these (and I had to use optional like that) is to make classes that provide RAII-like interface (noncopyable, nonmoveable) usable in contexts where I need to use two-phase initialization or to release the resource before the end of the scope (subject to some runtime condition) -- all that in order to have a resource acquired for as short span of time as possible. I would be forced to do that for std::lock_guard if the library did not provide a second template std::unique_lock. But not every library provides two interfaces for almost the same thing, and this is arguably an unnecessary redundancy for an interface. optional<RAII> as described above is a generic tool for transforming types that implement 'scoped ownership' into types that implement 'unique ownership' of a resource. Given this optional<RAII> pattern I can already re-set my object to a different resource: template< typename ...Args > void reset( boost::optional<RAII> & o, Args &&... args ) { o = boost::none; o = in_place( std::forward<Args>(args)... ); } Or perhaps boost::optional already implements this 'strange' assignment. I didn't have a need to reset a handle to a different resource. But you can see how (arguably) natural it becomes for optional<RAII>. Regards, &rzej