this makes sense

but not necessarily how it fits Alias (or how that's the "same" as an associated type)

the three sorts of aliases I see are:

type aliases (type Foo = Bar)
* these can always be "converted" from Foo to Bar, so there isn't really a need for a "placeholder" form

associated types (<T as Trait>::Bar)
* these can be converted into another type by finding an impl, if we can find one, so we might need a placeholder
* if we need a placeholder, then trait Trait { type Bar: Bounds; } the Bounds there are things we know about it

opaque impl trait types (type Foo = impl Bar)
* these can be converted from Foo to Bar only when in Reveal mode (during codegen), so we often need placeholders
* if we need a placeholder, then impl Bar plus auto-traits tells us what we know about it

and because with type Foo = impl Trait; type Bar = impl Trait;, Foo and Bar are not the same type

Not sure I understand; would that mean AliasTy would become an enum to hold that def-id?

On a related note, one of the things I've been thinking about with the type transition is that we should try to move rustc and chalk closer together by refactoring them both. so e.g. chalk has far fewer categories, and I think we might experiment with merging some of rustc's categories to make them line up. This may be a pain because parts of rustc wish to distinguish between types that chalk wouldn't, and we can decide if it's worth it -- it will also have some memory usage implications, which we would want to measure. In other words, I doubt we can pick the perfect variants a priori