TL;DR: We should look into passing pointer-shaped receivers using the context register.
Today, receiver parameters are effectively simply prepended to the parameter list. This was convenient when Go only had method expressions (i.e., expressions like T.M, where T is a type), because the same function code could be used for both method calls and method expressions.
However, Go later added method values (i.e., expressions like x.M, where x is a value), which require generating wrapper functions and also requires rather complex trampoline code within package reflect. This complexity is needed to adapt between the function closure calling convention (which passes the closure pointer using a dedicated context register) and the method calling convention (which passes receivers using a regular parameter).
If we change the internal calling convention so that receiver arguments are passed using the context register too, then we'd be able to avoid generating method value wrappers. We'd instead need just a single simple, universal wrapper, which could be used by both the compiler and package reflect. (For methods with non-pointer-shaped receivers, we would wrap the interface-calling-convention wrapper for the method, which always uses a pointer-shaped receiver parameter.)
Another benefit (pointed out by @dr2chase) is this would free up an extra register for passing arguments to pointer-receiver methods.
The only downside I see at the moment is that method expressions for pointer-shaped receiver types (e.g., (*T).M) would now need compiler-generated wrappers instead. However, the mitigating factors here are: (1) method expressions can only appear in source so we can always statically generate them (unlike for method values); (2) method expressions seem much less commonly used than method values (caveat: based on my anecdotal experience); and (3) it would be easy to reuse wrappers for methods with the same GC shape.
Since we're in the 1.18 freeze and there hasn't been any movement here, I'm going to place this in the backlog. IIUC this is still something we'd like to do, but unless anyone explicitly plans on working on it for next release, I'm reluctant to put it in the 1.19 milestone.