> I can't find an explanation in the Rust documentation but I expect the reason is that someone could implement another trait that provides .into_iter() on whatever the x is in for y in x, thus resulting in a compiler error because there would be two candidate implementations.

Because nothing in Rust is identifier-based. Unlike python, all syntax magic (even the ? operator) relies on traits defined by `core`.

    for x in y {

desugars to

    let mut iter = IntoIterator::into_iter(y);
    while let Some(x) = y.next() {

and

    x?

desugars to

    match x {
        Ok(x) => x,
        Err(e) => {
            return Err(From::from(e));
        }
    }

and

    x + y

desugars to

    core::ops::Add::add(x, y)

etc.

All of those traits are expected to live explicitly in the core crate at well known paths. Otherwise you'd be writing methods with absolutely no idea how the language would interact with it. And if you had a Set type implement `add`, it'd have to accept exactly 2 arguments to be compatible with the language's `add` or something equally as unergonomic.

It's traits all the way down! There'd be no explanation needed because it'd be antithetical and contradictory to traits to begin with. Once one understands how traits are intended to be used, the explanation for why there aren't identifier based resolution semantics becomes obvious.