Why are nested associated type paths considered ambiguous?

Question

Why are nested associated type paths considered ambiguous?

fn flatten<I>(iter: I) -> Option<I::Item::Item>
where
    I: Iterator,
    I::Item: IntoIterator,
{
    None
}

error[E0223]: ambiguous associated type
 --> src/lib.rs:1:34
  |
1 | fn flatten<I>(iter: I) -> Option<I::Item::Item>
  |                                  ^^^^^^^^^^^^^ help: use fully-qualified syntax: `<<I as Iterator>::Item as Trait>::Item`

Shouldn't the compiler be able to resolve the path without fully-qualified syntax? There is only one type I could be referring to, so I don't see why it is ambiguous. In this simple case it is not really a problem, but in more complex use cases, it becomes painful:

fn blah() -> <<<<A as B>::C as D>::E as F>::G as H>::I as J>::K> {}

Is this a limitation of the compiler or is it intended behavior?

Answer 1

This is a compiler limitation: Nested associated type projection is overly conservative #38078. There's a bit of hope that chalk will improve the situation, but there's no guarantee that it will.