Consider the following code (playground):

type R(type T) struct{}
func F(type T)() {
     _ = func() R(T) { return R(T){} }
}

That is, we have some parameterized type R(T), and a function literal which returns that type R(T). (This is simplified from an example I found while writing generic composition with a result type.)

This currently fails with the following error message: prog.go:5:23: expected operand, found 'return' (the referenced location is indeed the return). (As an aside, this error message was pretty opaque -- not sure if improving that sort of thing is in-scope for the prototype.)

The issue appears to be a parsing ambiguity similar to the one described in the design draft, where func() R(T) has been interpreted as (func() R)(T). But the solution described there doesn't work: writing func() (R(T)) gets parsed as (and gofmted to) func() (R T). That is, it runs into another parsing ambiguity described in the draft. As a further workaround, I eventually realized to use func() (_ R(T)); from there things work fine.

Presumably the solution to the second parsing ambiguity could also work here, if applied to function returns; of course that expands the compatibility break described there. Or, this could be documented similar to [](R(T)).

See also golang-nuts thread.