I'm pretty sure that this would be an example of a "dependently-sized type" that the error message mentions. As I understand it, transmute expects to know the exact size at the call site. Since the <T as Foo<'_>>::Output projections can't be normalized into a specific type, transmute does not attempt to do any further reasoning. See also rust-lang/rust#61956; a type with a const-generic size can't be transmuted.
Do you have an example of how this could happen? I see a few open issues for unsoundness with specialization, but I'm not sure how I would use one of them to get different layouts. They mostly seem to give you a way to turn &'a T into &'static T, but that's not what I'm worried about here.
Curiously, 'static specialization seems to override any lifetime-generic defaults. Consider this basic example (Rust Playground):
#![feature(specialization)]
pub trait Trait<'a> {
type AssocType;
}
pub struct Struct;
impl<'a, T> Trait<'a> for T {
default type AssocType = ();
}
impl Trait<'static> for Struct {
type AssocType = i32;
}
pub fn test<'a>() -> <Struct as Trait<'a>>::AssocType {
unimplemented!()
}
The compiler complains that Struct only implements Trait<'static>. But if the second impl block is commented out, the code compiles with only the incomplete_features lint.
Reading through the issue that @LegionMammal978 linked as well as related issues, it looks like std::mem::transmute just doesn't work on type parameters in general. For example, std::mem::transmute::<T, T>(...) returns the same error even though T and T are clearly the same type.