It's not generic vs non-generic, but concrete type vs interface type. Change F to get in an interface, it also prints 9:

func F(x I) {
	defer x.P()
	x.M(9)
}

AFAICT, this behavior is right. According to the spec:

For a value x of type I where I is an interface type, x.f denotes the actual method with name f of the dynamic value of x.

But &s is not an interface. That is the problem.

May be related to #52025.

CC @randall77 @mdempsky

@dmitshur I think this should be a new problem, instead of a backlog problem.

As @cuonglm points out, the generic code using type parameters behaves the same as how interface calls work. Ack that this differs from how the same code would work when specialized to execute with a single, concrete type argument.

I think this is a spec ambiguity issue. The semantics around promoted methods, interface method calls, method values, and defer statements are still fuzzy, IMO.

It looks this specified problem is more about the inconsistency between interface method value and non-interface method value evaluation:

package main

type I interface {M(int); P()}

type V int
func (v *V) M(n int) {*v = V(n)}
func (v V) P() {print(v)}

func F(x *V) {defer x.P(); x.M(7)}

func G[T I](x T) {defer x.P(); x.M(7)}

func H(x I) {defer x.P(); x.M(7)}

func main() {
	F(new(V)) // 0
	G(new(V)) // 7
	H(new(V)) // 7
}

It really breaks many people's expectations to view type parameters always as interfaces.