Thanks for the clarification, I actually had some issues understanding your example. What I'm trying to say is that when the compiler generates the vtable for the invisible sub-trait of Foo + Bar, we have to force it to always generate the same vtable (within a compiler run), without changes in the layout or the function pointer order; i.e., the vtable must be deterministic. However, if we add another trait bound to the dyn, it would become incompatible, because the layout isn't guaranteed to be the same anymore (the same would happen with the manual implementation). In other words, we can't downcast a dyn Foo + Bar into a dyn Foo or a dyn Bar, at least without magic. Maybe we can swap the vtable pointer, but I don't know to which extend that's viable.