It helps with the overall goal of optimizing code for types, but I wouldn't say it changes the principles. The principle remains that generics are type-checked at definition time, and Rust tries to avoid having monomorphisation-time type errors.
• When you have `impl<T> Trait<T> for MyType` you still can't make any type-specific assumptions about T in this impl, even with specialization.
• When you have `impl Trait<i32> for MyType` then you can rely on the specific type, even without specialization.
So rules for individual implementations remain unchanged, specialization merely allows both implementations to coexist.
I think we agree that Rust allows generic code to be constrained, which means it can be eagerly type checked at the definition site. Contrast to C++ templates which are unconstrained meaning the compiler can't type check until they're expanded (barring the use of concepts).
What I was trying to say is that whether or not concrete type of a generic argument can be used as a constraint is orthogonal to those semantics, it's an implementation detail.
Not on principle, but an incomplete/unstable feature called specialization: https://github.com/rust-lang/rust/issues/31844