Yeah, n separate arguments versus a single n-tuple argument is another annoying case, but despite being more common, I find it easier to explain as necessary, since fn(A, B) is "obviously" different from fn((A, B)), but with |a, b| f(a, b) the difference is entirely in implicit coercions.
For this case I'm personally satisfied with a future combinator able to convert between impl Fn(Args...,) -> Ret and impl Fn((Args...,)) -> Ret, so long as the same one works independent of fn quality (i.e. once/mut).
Another related thing that trips me up is vec_of_s.iter_mut().map(S::method_that_takes_immutable_self);, which doesn't compile because of the mutable vs immutable reference.
I'd love to have this exact syntax work, along with _::EnumVariant and similar.
I would not expect that to work; I don't think the same intuition supporting _::foo would support _.foo(), because the latter implies inserting a lambda, while the former is just an inference extension to T::foo.