See: rust-lang/rust#108684 and this zulip discussion

Firstly, let's assume that ManuallyDrop::drop() is equivalent to ptr::drop_in_place() since the docs claim they are.

ManuallyDrop::drop() makes an interesting claim:

Other than changes made by the destructor itself, the memory is left unchanged, and so as far as the compiler is concerned still holds a bit-pattern which is valid for the type T.

This can be parsed in two ways:

(Other than changes made by the destructor itself, the memory is left unchanged), and so as far as the compiler is concerned still holds a bit-pattern which is valid for the type T.

and

Other than changes made by the destructor itself, (the memory is left unchanged, and so as far as the compiler is concerned still holds a bit-pattern which is valid for the type T.)

The question becomes: is Drop::drop() allowed to invalidate the type? Is it fine for its body to be *self = uninit or e.g. for a bool something like *self = transmute(73)?

This has different implications in a world with shallow vs deep validity (#77), because if there is deep validity this means that it might be insta-UB to pass an &mut T to ptr::drop_in_place() (otoh it might be insta-UB to write a Drop impl that invalidates its own &mut self, so it still could be okay, depending on precisely how long validity is supposed to last)

As it currently stands with the ambiguity, the note of "as far as the compiler is concerned still holds a bit-pattern which is valid for the type T." is not really useful. We should figure out what it means, and clarify the docs to say so.