That wouldn’t be an issue. The whole claim is that this:

    let a: u8 = /* */;
    let b: u16 = a;
    push_u16(a);

can easily be inferred into: (no pun intended)

    let a: u8 = /* */;
    let b: u16 = a.into();
    push_u16(a.into());

But the Rust language has decided that implicit upconversion that is already apparent is a bad idea because “bugs”. And I’d agree with them, but it’s stupid in this case. The issue at hand isn’t asking for ‘a’ to be upconverted to a u16 in the middle of an expression like this:

    let b: u16 = a + 1;

…because you’d be left with the question of when to upconvert (“implicitly changing behavior” as you call it). No, it would only be when it shouldn’t need to be said such as a lone assignment or function call.

And if the Rust language’s argument is that it’d be unclear when it’s allowed? Because I’ve seen many RFCs where someone does what you just did: “what about this weird corner case where ‘u8 max + 1’? Should that be a u8 or u16? Maybe we should toss the whole proposal!” To that I’d say: start off where it’s clear (like my examples above). It’s not a backwards incompatible change.

/rant