As Liam Breck said, changing the function signature by adding more round parentheses would make it very hard to read it. I personally found something like
func (/*receiver*/)Foo(/*types*/)(/*args*/)(/*return tuple*/){
c,d := a.Foo(Type)(e,f)
to be way too complex compared with the usual go syntax.
I read the section on characters and the following ones, but I don't think that justifies the loss on readability.
Generics are already a complex thing by themselves, without making them hard do read. I think generics should be used as little as possible, and we should provide something that highlights there is an unusual feature being exploited. If the need is having a bounded lookahead in the compiler, even replicated characters could fit the purpose. Reading something like
func(/*receiver*/)Foo<<<Type>>>(/*args*/)(/*return tuple*/)
c,d := a.Foo<<<Type>>>(e,f)
makes it very clear that we are using a generic,
gives room for the eyes to adjust and understand what is going on, and since <<< is not a valid sequence just requires a bounded lookahead. (This is also true for many other ascii characters, like pipes or backticks)
I'm not saying this one with < should be the syntax we end up with, but please think about alternatives.
Generics are going to save a lot of lines of code, I don't think adding 4 more characters per use/declaration is going to be an issue.
NOTE: this would also look better in my opinion
func(/*receiver*/)Foo`Type`(/*args*/)(/*return tuple*/)
c,d := a.Foo`Type`(e,f)
Biggest and the most Important use of generics (imo) is data structures like list, iterators, promises, and observables.
The drawback is on the function parameter, reciever, and the return which consumes multiple parenthesis and line width (actually).