seems reasonable; if it's going to be in std::ptr, I see no compelling reason for a longer name. For other examples of names that rely on the reader knowing where they're coming from in order to make sense of them, consider std::cell::Ref, std::ptr::eq or std::iter::Map.
Of course, if people are going to be using it in a context where they have other Metadatas floating around, they can always use it as PointeeMetadata or whatever.
¯\_(ツ)_/¯ I haven't thought about that too much. It'd be an interesting way to support associated trait functions... though this would I think live on DynMetadata, not 🚲, which is for any pointee.
The typical (and perhaps only?) use-case is talking a normal (potentially fat) pointer, calling to_raw_parts, and then storing the pointer in decomposed form. This is most beneficial when doing something like the Storage API abstracts over, where you don't store the data pointer directly but rather some key information which allows you to retrieve the data pointer.
It's growing on me, especially if the other ptr_metadata APIs are adjusted to return it rather than it just being a wrapper you use to get CoerceUnsized.
ptr::metadata::<T> is always monomorphized over T, as is even <T as Pointee>::Metadata. I don't think returning ptr::Metadata<T> will change the amount of monomorphized code written.
The latter is <T as Pointee>::Metadata. While std could include a type alias for this, I don't think it necessary, and it'd only serve to increase the "what's the difference" between the transparent alias and the retyped newtype.