Yes, this is an unfortunate loss of information (in retrospect, a nice goal for go/types would be to lose no information, but it took me a long time to realize that).

Supposing we wanted to fix this, I can think of two approaches:

1. Add another map to types.Info.
2. Add a new CheckExpr-like API that works the way we want.

I feel like I'd rather invest in (2), though I can't say for certain that it is feasible. What do others think?

If #62664 (comment) we might be able to invoke it on the argument expression (effectively, with no context) to see what type it gives.

I was unnecessarily critical of CheckExpr. It solves this problem neatly.

My worry about CheckExpr with no context is more complex expressions with constants:

func f(x int16) { y := x; _ = (*int16)(&y) }
const c = 1
f(c+2) // inline

Change https://go.dev/cl/530975 mentions this issue: internal/refactor/inline: insert conversions during substitition

My worry about CheckExpr with no context is more complex expressions with constants:
func f(x int16) { y := x; _ = (*int16)(&y) }
const c = 1
f(c+2) // inline

With my pending CL 530975, this example inlines to:

            	const c = 1
            	{
            		y := int16(c + 2)
            		_ = (*int16)(&y)
            	}

which is correct.