You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.
That's a fair point, but there are still times when being explicit is useful or even required, and it doesn't hurt to use syntax that disambiguates easily.
When a function returns a function, you rarely just call it immediately in Go. But even if that were common (and maybe it would become common with generics? I'd have to think that through) it is uncommon to have a type name as unrecognizable as 'x'.
I've always been a big advocate for unambiguous, clear code, especially in Go, but I don't see a big potential for confusion here.
I don’t want to overstate the problem; I think it is a bit less readable. While types are rarely so indescriptive as “x”, they are often still plenty indescriptive, and I don’t know why we should introduce a syntax that depends on the clarity of type names or the frequency of other potentially ambiguous constructs when we could use a syntax that is unambiguous with no caveats and friendlier/more familiar to the larger body of programmers who have not yet tried Go.