Negative trait bounds using feature(specialization)

The true sealed trait language construct is particularly powerful when combined with specialization. It ensures that all implementations of the trait—whether they are blanket or specialized—can only be defined within the crate that declares the trait. This effectively prevents any external crate from providing its own specialized impl that could override the original crate's default behavior.

In contrast, the traditional private supertrait pattern (i.e., pub trait Trait: private::Sealed) can prevent new, non‑specialized implementations for external types, but it fails to block external specialized impls. The reason is that the private supertrait is often paired with a blanket impl<T> private::Sealed for T {} to allow external types to receive the default behavior. However, this blanket impl inadvertently gives external crates a "pass" to satisfy the supertrait, enabling them to write a more specific impl that will override the default via specialization. Thus, the private supertrait offers only a superficial barrier, while a true sealed keyword would enforce a definition‑site restriction that is immune to such override attacks.

This eliminates the type-equality ambiguity that currently plagues patterns like where Indirect<T>: CopyImpled<Impled = False>, and would render the current workaround (e.g., the Is trait trick) completely obsolete.