Named opt-in trait impls

We all know that from inference perspective, all impls are "global" if not excluded with coherence. So this is actually part of the "inference API" of a crate. (But not yet well documented by tools like rustdoc to this day, sadly)

I've seen many tragedies that are straightforward outcome of this.

But i feel we should have patching tools that move ourselves forward, if this is not solvable problem in the near future.

What if we could opt-out an impl from the implicit parts of inference?

Strawman proposal: Named opt-in trait impls.

#[optin_impl(u8_idx)]
impl Index<u8> for [T] {
      // impl
}

fn foo1() {
     dbg!([1,2,3][3u8]);    // Doesn't compile, because no impls is selectable
     dbg!([1,2,3][3usize]);    // Works fine as always, with `usize` as idx,
     dbg!([1,2,3][3]);    // Works fine as always, with `usize` as idx,
}

#[use_optin_impls(u8_idx, ...)]
fn foo2() {
     dbg!([1,2,3][3u8]);    // Works fine, with `u8` as idx,
     dbg!([1,2,3][3usize]);    // Works fine, with `usize` as idx,
     dbg!([1,2,3][3]);    // Doesn't compile, because two impls are both in effect     
}

The issue names no files, tests, or implementation entry points. Start by reviewing the proposed Rust syntax and its interaction with trait coherence and inference, then determine the design and RFC work needed; done would require an agreed, implementable proposal rather than a small code change.