Syntactically rejecting impl-Trait inside non-final path segments & inside fn ptr types is futile

This concerns both universal and existential impl-Trait.

Since #48084 (2018) we reject impl-Trait inside qselves and non-final path segments (during AST validation lowering (since #132214)).
Since #45918 (2017) we reject impl-Trait inside fn ptr types (during AST lowering).

However, both checks are purely syntactic / syntax-driven as they happen before HIR analysis[^1].
Therefore we can simply circumvent them by introducing indirection via type aliases.

Examples:

fn proj_selfty_e_neg() -> <impl Sized as Mirror>::Image {} // 🔴 REJECTED: `impl Trait` is not allowed in path parameters
fn proj_selfty_e_pos() -> MirrorImage<impl Sized> {} // 🟢 Workaround: ACCEPTED

fn proj_selfty_u_neg(_: <impl Sized as Mirror>::Image) {} // 🔴 REJECTED: `impl Trait` is not allowed in path parameters
fn proj_selfty_u_pos(_: MirrorImage<impl Sized>) {} // 🟢 Workaround: ACCEPTED


fn qself_trait_u_neg(_: <() as Carry<impl Sized>>::Project) {} // 🔴 REJECTED: `impl Trait` is not allowed in path parameters
fn qself_trait_u_pos(_: Project<impl Sized>) {} // 🟢 Workaround: ACCEPTED


// <> under `#![feature(inherent_associated_types)]` only
fn non_final_seg_u_neg(_: Transp<impl Sized>::InhProject) {} // 🔴 REJECTED: `impl Trait` is not allowed in path parameters
fn non_final_seg_u_pos(_: InhProject<impl Sized>) {} // 🟢 Workaround: ACCEPTED
// </>


fn fn_ptr0_e_neg() -> fn() -> impl Sized { || {} } // 🔴 REJECTED: `impl Trait` is not allowed in `fn` pointer return types
fn fn_ptr0_e_pos() -> FnPtrOut<impl Sized> { || {} } // 🟢 Workaround: ACCEPTED

fn fn_ptr1_e_neg() -> fn(impl Sized) { |()| {} } // 🔴 REJECTED: `impl Trait` is not allowed in `fn` pointer parameters
fn fn_ptr1_e_pos() -> FnPtrIn<impl Sized> { |()| {} } // 🟢 Workaround: ACCEPTED

fn fn_ptr_u_neg(_: fn(impl Sized)) {} // 🔴 REJECTED: `impl Trait` is not allowed in `fn` pointer parameters
fn fn_ptr_u_pos(_: FnPtrIn<impl Sized>) {} // 🟢 Workaround: ACCEPTED

//////////////////////////////////////////////////

trait Mirror { type Image; }
impl<T> Mirror for T { type Image = T; }
type MirrorImage<T> = <T as Mirror>::Image;

trait Carry<T> { type Project; }
impl<T> Carry<T> for () { type Project = (); } 
type Project<T> =  <() as Carry<T>>::Project;

// <> under `#![feature(inherent_associated_types)]` only
struct Transp<T>(T);
impl<T> Transp<T> { type InhProject = (); }
type InhProject<T> = Transp<T>::InhProject;
// </>

type FnPtrOut<O> = fn() -> O;
type FnPtrIn<I> = fn(I);

This calls into question the very existence of these checks.

Should we just remove them? Are they historical remnants? Or should we keep them to prevent users from shooting themselves into the foot? Some of these types are actually quite useful (e.g., the fn() -> impl Sized as seen in fn_ptr0_e_neg) but a lot of them are not at all what you want. Some of them are completely useless (by containing unredeemably uninferable types). I don't think any of them lead to soundness issues.

[^1]: They could've been syntactic modulo (eager) type alias expansion (≠ normalization).

The issue names the checks associated with #48084 and #45918 but no source files or tests. Start by locating those AST validation/lowering checks and reproducing the listed type-alias workarounds. Done requires a decided policy for these forms plus compiler changes and regression coverage for the accepted and rejected examples.