RPITITs are not simple opaque types

As stated in the RFC itself, the desugaring of RPITIT in the trait definition only results in associated types, there is no impl Trait in the desugared form: https://github.com/tmandry/rfcs/blob/rpitit/text/0000-return-position-impl-trait-in-traits.md#equivalent-desugaring-for-traits.

The desugaring for impls then uses a TAIT as the expected type for the anonymous associated type generated for the RPIT in the trait definition.

Unlike other impl Trait, RPITIT does not represent "some type that implements Trait", but instead means "each impl will provide some type that implements Trait". Unlike other impl Trait, RPITIT has the issue that users want to be able to write bounds for RPITIT.

An alternative desugaring for RPITIT would be the following:

trait NewIntoIterator {
    type Item;
    fn into_iter(self) -> impl Iterator<Item = Self::Item>;
}

// becomes
type $<T: NewIntoIterator> = impl Iterator<Item = T::Item>;
trait NewIntoIterator {
    type Item;

    fn into_iter(self) -> $;
}

Now, that desugaring would very rarely be useful, but it does feel more consistent to me.