Nightly regression - Option::cloned method resolution

[CAD97]

unic-ucd-normal (and thus the supercrate unic) was compiling on rustc 1.21.0-nightly (e26688824 2017-08-27) but fails on rustc 1.21.0-nightly (c11f689d2 2017-08-29). (This is with the unpublished version at https://github.com/behnam/rust-unic/tree/master/unic/ucd/normal only.)
Passing build & Failing build

   Compiling unic-ucd-normal v0.5.0 (file:///D:/Christopher/Documents/Code/Rust/rust-unic/unic/ucd/normal)
error[E0034]: multiple applicable items in scope
  --> unic\ucd\normal\src\lib.rs:63:65
   |
63 |         canonical_composition(a).and_then(|table| table.find(b).cloned())
   |                                                                 ^^^^^^ multiple `cloned` found
   |
   = note: candidate #1 is defined in an impl for the type `std::option::Option<&_>`
   = note: candidate #2 is defined in an impl for the type `std::option::Option<&mut _>`

This appears to be #43738 (tracking) / #43705 (impl) that is causing this. Note that we do not have #![feature(option_ref_mut_cloned)] (it didn't exist until today(?)).

Small reproduction in #44208 (comment)

[Mark-Simulacrum]

Nominating for @rust-lang/libs. Not sure if we can do much about this -- I'd expect this not to happen, as mutability shouldn't be inferred in most cases? A smaller example would definitely be helpful.

[CAD97]

@Mark-Simulacrum I got one! It's a bit weird...

https://play.rust-lang.org/?gist=ca256a29f753fe800b3a5673f4a7efa7&version=stable

trait DataTable<V> {
    fn find(&self, needle: char) -> Option<V>;
}

impl<'a, V> DataTable<&'a V> for &'a [(char, V)] {
    fn find(&self, needle: char) -> Option<&'a V> {
        self.binary_search_by_key(&needle, |&(k, _)| k)
            .map(|idx| &self[idx].1)
            .ok()
    }
}

impl DataTable<()> for &'static [(char, char)] {
    fn find(&self, _: char) -> Option<()> {
        Some(())
    }
}

fn main() {
    static TABLE: &[(char, char)] = &[('a', 'a')];
    let x: Option<char> = TABLE.find('a').cloned();
}

It seems to be caused by the two impls here, as removing the second eliminates the error (which is why I was having trouble finding a small reproduction)

[EDITED with smaller example. Previous]

(If anyone is curious why we have [(char, V)] and [(char, char)] as DataTables, the reason is that the former is a mapping from char to some value, while the latter is range-based inclusion set. I'm in the process of changing the tuple to a dedicated inclusive range type.)

[behnam]

It looks like the actual ambiguity is cause by having implementations for both (char, V) and (char, char) types, and is not actually about ref vs mut-ref; BUT, the error detection is confused and errs on the latter, instead of the former. It seems like this confusion could be the bug that needs to be fixed here.