OIBIT behaviour with primitives (specifically references) doesn't seem perfected

#![feature(optin_builtin_traits)]

trait NoImpl {}
impl NoImpl for .. {}
fn test_no_impl<T: NoImpl>() {}

trait ConcreteImpl {}
impl ConcreteImpl for .. {}
fn test_concrete_impl<T: ConcreteImpl>() {}

impl<'a> ConcreteImpl for &'a i16 {}

trait GenericImpl {}
impl GenericImpl for .. {}
fn test_generic_impl<T: GenericImpl>() {}

trait Bound {}
impl<'a, T: Bound> GenericImpl for &'a T {}

fn main() {
    test_no_impl::<&u8>();
    test_concrete_impl::<&u8>();
    test_generic_impl::<&u8>();
}

Fails to compile with:

<anon>:23:5: 23:29 error: the trait `Bound` is not implemented for the type `u8` [E0277]
<anon>:23     test_generic_impl::<&u8>();
              ^~~~~~~~~~~~~~~~~~~~~~~~

In particular, adding a generic impl of a trait has effectively removed other implementations (i.e. comparing against the behaviour when that impl wasn't there). It seems like this behaviour is somewhat idiosyncratic, and may want to be fine tuned.

The RFC doesn't seem to discuss references (or even primitives) at all, so I'm unsure if this has been thought about much.

(NB. the safety of Send and Sync is actually relying on this behaviour at the moment, so changes to this may have to change how the impls are arranged in core. Although I would prefer a solution that doesn't require changing them, as that will be making safety the default.)

cc @rust-lang/lang

Start by compiling the provided Rust reproducer, then compare the result with and without the generic GenericImpl implementation. Read RFC 0019, especially its treatment of opt-in builtin traits, and determine the intended behavior for references and primitives. Done requires an agreed semantic change and corresponding compiler or core adjustments, since the issue notes possible safety implications.