[ 2011-06-12: Daniel comments and provides wording ]

According to my understanding of the mental model of vector (and to some parts for deque) the some requirements are missing in the standard as response to above questions:

1. The preconditions of shrink_to_fit for both std::vector and std::deque should impose the MoveInsertable requirements. The reason for this is, that these containers can host move-only types. For a container type X the C++03 idiom X(*this).swap(*this) imposes the CopyInsertable requirements which would make the function call ill-formed, which looks like an unacceptable restriction to me. Assuming the committee decides to support the move-only case, further wording has to be added for the situation where such a move-only type could throw an exception, because this can leave the object in an unspecified state. This seems consistent with the requirements of reserve, which seems like a very similar function to me (for vector). And this brings us smoothly to the following bullet:

2. I agree that we are currently missing to specify the preconditions of the reserve function. My interpretation of the mental model of this function is that it should work for move-only types, which seems to be supported by the wording used in [vector.capacity] p2:

   […] If an exception is thrown other than by the move constructor of a non-CopyInsertable type, there are no effects.

   Given this statement, the appropriate requirement is MoveInsertable into the vector.

3. I agree that vector::resize(size_type) misses to list the DefaultConstructible requirements.
4. Unfortunately the current specification in terms of erase implies the MoveAssignable requirements. I don't think that this implication is intended. This function requires "append" and "pop-back" effects, respectively, where the former can be realized in terms of MoveInsertable requirements. The same fix in regard to using pop_back instead of erase is necessary for the two argument overload of resize as well (no MoveAssignable is required).
5. The CopyInsertable requirement is incorrect and should be MoveInsertable instead.

In addition to above mentioned items, the proposed resolution adds a linear complexity bound for shrink_to_fit and attempts to resolve the related issue 2066.