Varying diagnostics for multiplying Option<i32> and u32/i32, depending on how the call is written

Code

// https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8432adbd1c12bd8e71fd388725efaf45

use std::ops::Mul;
fn main() {

    // This should suggest expect
    // Stable (1.73.0):     No help             Bad
    // Nightly (1.75.0-n):  No help             Bad
    let abs = 7i32.checked_abs();
    let answer = abs * 5u32; // Case 1

    // This should suggest expect
    // Stable (1.73.0):     Others implement trait `Mul<Rhs>    Bad
    // Nightly (1.75.0-n):  Others implement trait `Mul<Rhs>    Bad
    let abs_2 = 7i32.checked_abs();
    let answer_2 = 5u32 * abs_2; // Case 2

    // This should suggest expect
    // Stable (1.73.0):     Suggested expect    Good :)
    // Nightly (1.75.0-n):  Suggested expect    Good :)
    let abs_3 = 8i32.checked_abs();
    let answer_3 = abs_3.mul(3); // Case 3

    // This should suggest expect
    // Stable (1.73.0):     Others implement trait `Mul<Rhs>    Bad
    // Nightly (1.75.0-n):  Others implement trait `Mul<Rhs>    Bad
    let abs_4 = 9i32.checked_abs();
    let answer_4 = 9i32.mul(abs_4); // Case 4
}

Current output

Compiling playground v0.0.1 (/playground)
error[E0369]: cannot multiply `Option<i32>` by `u32`
 --> src/main.rs:8:22
  |
8 |     let answer = abs * 5u32; // Case 1
  |                  --- ^ ---- u32
  |                  |
  |                  Option<i32>

error[E0277]: cannot multiply `u32` by `Option<i32>`
  --> src/main.rs:14:25
   |
14 |     let answer_2 = 5u32 * abs_2; // Case 2
   |                         ^ no implementation for `u32 * Option<i32>`
   |
   = help: the trait `Mul<Option<i32>>` is not implemented for `u32`
   = help: the following other types implement trait `Mul<Rhs>`:
             <u32 as Mul>
             <u32 as Mul<Duration>>
             <u32 as Mul<&u32>>
             <&'a u32 as Mul<u32>>
             <&u32 as Mul<&u32>>

error[E0599]: no method named `mul` found for enum `Option` in the current scope
  --> src/main.rs:20:26
   |
20 |     let answer_3 = abs_3.mul(3); // Case 3
   |                          ^^^ method not found in `Option<i32>`
   |
note: the method `mul` exists on the type `i32`
  --> /rustc/189d6c71f3bb6c52113b5639a80839791974fd22/library/core/src/ops/arith.rs:328:5
help: consider using `Option::expect` to unwrap the `i32` value, panicking if the value is an `Option::None`
   |
20 |     let answer_3 = abs_3.expect("REASON").mul(3); // Case 3
   |                         +++++++++++++++++

error[E0277]: cannot multiply `i32` by `Option<i32>`
  --> src/main.rs:26:29
   |
26 |     let answer_4 = 9i32.mul(abs_4); // Case 4
   |                         --- ^^^^^ no implementation for `i32 * Option<i32>`
   |                         |
   |                         required by a bound introduced by this call
   |
   = help: the trait `Mul<Option<i32>>` is not implemented for `i32`
   = help: the following other types implement trait `Mul<Rhs>`:
             <i32 as Mul>
             <i32 as Mul<&i32>>
             <&'a i32 as Mul<i32>>
             <&i32 as Mul<&i32>>

Some errors have detailed explanations: E0277, E0369, E0599.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `playground` (bin "playground") due to 4 previous errors

Desired output

In an ideal world, I would expect the same help for each line - probably a suggest to expect the Option.

Some operators clearly are not commutative, but I would have thought * was. I've used it instead of + to avoid did you mean .and() clutter but it's the same result there as well.

Given similar code is generated for the operator and the method call (I don't know what the exact code the operator generates is checked/unchecked wise) naively one would expect a similar set of help generated.

I can see why the compiler has more information when the LHS type is concrete, but it's a bit unfortunate.

Rationale and extra context

Playground

Other cases

No response

Anything else?

No response

Reproduce the four cases from the linked Rust Playground and compare their diagnostics, especially the differing suggestions for operator and method-call syntax. Trace the compiler diagnostic paths responsible for E0369, E0277, and E0599, then add or update focused tests so equivalent cases provide consistent Option-unwrapping help.