[Moved to DR at the May, 2015 meeting.]

Proposed resolution (April, 2015):

Change 11.4.5.3 [class.copy.ctor] paragraph 31 as follows:

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the constructor selected for the copy/move operation and/or the destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and. If the first parameter of the selected constructor is an rvalue reference to the object's type, the destruction of that object occurs when the target would have been destroyed; otherwise, the destruction occurs at the later of the times when the two objects would have been destroyed without the optimization.¹²² This elision of copy/move operations, called copy elision, is permitted...

When copy elision is performed, the lifetime of the merged object ends at the later of the times the two objects' lifetimes would have ended. If the copy elision is done using a move constructor, however, it might make sense to assume that the moved-from object's lifetime is no longer interesting and the lifetime should be that of the moved-to object.