Almost certainly nothing happens to the current content if the new allocation fails, because nothing can happen before there’s a new allocation to which to move the data. So explicitly specifying this was probably overlooked as being "too obvious" from an implementer’s viewpoint – but I agree that it (and such exception safety invariants in general) should definitely be documented in detail! Any &mut-taking function that returns a Result should document what state the argument/receiver is left in, whether the result is a success or a failure.
It should probably be documented better, but all of the try_reserve[_exact]() functions have the semantics of Allocator::grow() in practice (emphasis mine):
If this returns Ok, then ownership of the memory block referenced by ptr has been transferred to this allocator. The memory may or may not have been freed, and should be considered unusable unless it was transferred back to the caller again via the return value of this method.
If this method returns Err, then ownership of the memory block has not been transferred to this allocator, and the contents of the memory block are unaltered.