Unless I'm mistaken, this code:

type Bar[T any] struct{ v T }

func (b Bar[int]) bar() int { return b.v }

Is equivalent to:

type Bar[T any] struct{ v T }

func (b Bar[T]) bar() T { return b.v }

It compiles because you've used the name int for the type parameter in that method's scope; it's not being specialized to int, it's just a type variable that happens to be called int (and b.v is of the same type, though defined with a different name).

If I write:

type Bar[T any] struct{ v T }

func (b Bar[something]) bar() something { return 42 }

The error message is cannot use 42 (untyped int constant) as something value in return statement.

The return 42 example fails because 42 isn't compatible with struct{}, and the b.v + b.v example doesn't compile because + is not defined for any.

Interesting. So type parameters in type definitions are universally quantified, but type indices (?) in method definitions act more like existentials. This is somewhat strange because type parameters in non-method functions are universals.

A definition like

func (b Bar[int]) bar() int { return b.v }

just means that for the body of the method, the type parameter is named int. It's no different from writing

func (b Bar[MyTypeParameterName]) bar() MyTypeParameterName { return b.v }

Remember that in Go int is not a keyword, it's just a predeclared identifier. Using it as a type parameter name in a method declaration shadows the predeclared definition.

Similarly, this is valid Go;

func F(int string) string { return int }