The old solver does not support the concept of normalizes-to, we always have the fallback to equating as a rigid projection behavior. It should be safe to maintain that behavior with the new solver as well and then maybe change it at some point in the future. how projection goals work in the new solver One-step normalization can either assemble no candidates, keep the term unconstrained, or actually constrain it in some way. how projection goals work in the old solver If we fail to project, equate the term with a rigid projection. In case of ambiguity, we stall. We make inference progress if selection results in a single candidate. We do not evaluate nested goals during selection if there is only a single candidate, which is different in the new solver. If selection succeeds ignoring nested goals, but fails once we evaluate them, this means that there was a single impl candidate and no candidates from the ParamEnv. This case would error in the old solver and result in a 'rigid projection' in the new one. Given that such a projection is not WF we error either way.

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;