@Centril your point about foo.[await bar] case was significant. After thinking about it, I decided to slightly change semantics to desugar this snippet to { let _it = foo; { await bar } }.
Rationale: if we would have foo.[await bar] resolving to await (foo.bar) then it will shadow local variables and we wouldn’t be able to access them on the same place; moreover, foo.[await it.bar] can produce exactly the same result. New syntax either provides access to local variables and don’t has this ambiguity. Even I think that it’s easier to understand, since only methods now requires a special support for it.
And there’s use case for that syntax: it allows to change subject of method call chain.
Edit: however this makes the purpose of extended dot syntax less specific. The following rule would be simpler: only associated items and expressions that uses it in top level scope are valid in extended dot context .