Well-formedness (e.g. `where` bound from struct) unenforced in associated types

While trying out variants of the code in #154172, I came up with this example

trait Bound {}
struct Bounded<B: Bound>(B);

trait Tr {
    type TrAssoc;
}
impl<T> Tr for T {
    type TrAssoc = i32;
}

trait Simple {
    type SimpleAssoc;
}

impl Simple for () {
    type SimpleAssoc = <Bounded<()> as Tr>::TrAssoc; // okay?
}

fn main() {
    // let n: <Bounded<()> as Tr>::TrAssoc = 123; // error
    let n: <() as Simple>::SimpleAssoc = 123; // okay?
}

It seems inconsistent that <Bounded<()> as Tr>::TrAssoc is disallowed in main, but not an issue if used in type SimpleAssoc = … (even when that associated type is later used in main).

I have – thus far – no reason to suspect this is causing unsoundness; but it seems unfortunate that () can be passed to Bounded without fulfilling (): Bound even when the concrete type, then, is largely irrelevant for it’s unused in the blanket impl of trait Tr, and the whole thing normalizes to i32

Interestingly, the first line in main too used to compile before Rust 1.68. I bisected that change more precisely to this range

get_commits_between returning commits, len: 7
  commit[0] 2023-01-08: Auto merge of #106449 - GuillaumeGomez:rustdoc-gui-retry-mechanism, r=Mark-Simulacrum
  commit[1] 2023-01-08: Auto merge of #90291 - geeklint:loosen_weak_debug_bound, r=dtolnay
  commit[2] 2023-01-09: Auto merge of #106616 - compiler-errors:rollup-emcj0o3, r=compiler-errors
  commit[3] 2023-01-09: Auto merge of #106582 - compiler-errors:better-spans-on-bad-tys, r=lcnr
  commit[4] 2023-01-09: Auto merge of #106340 - saethlin:propagate-operands, r=oli-obk
  commit[5] 2023-01-09: Auto merge of #101947 - aliemjay:astconv-normalize, r=lcnr
  commit[6] 2023-01-09: Auto merge of #106637 - fee1-dead-contrib:rollup-ticvmsd, r=fee1-dead

and I'm suspecting the PR for that improvement (rejecting more problematic code) might have been #101947

Start by compiling the Rust reproducer in the issue and comparing the two associated-type uses. Then inspect the seven-commit regression range, especially PR #101947; done means the compiler consistently enforces well-formedness for both cases, with tests covering the observed behavior.