There are many ways to write ambiguous code in Go, or in any
programming language. The interesting question here is not "can it be
ambiguous?" It is "will it be ambiguous in practice?" That is why I
am encouraging people to write real code using the design draft, so
that we can see how that real code looks.
In particular, the ambiguity in your example hinges on a collision
between a variable name and a type name. In Go, for better or for
worse, variable names and type names live in the same namespace and
can shadow each other. Yet people are rarely confused by this in
practice. Real code rarely uses identifiers like "foo". In real
code, when we look at an identifier, how often are we confused as to
whether that identifier is a variable, a function, a type, or a
constant? And how often do those confusing cases collide with a case
like a function that returns a function that is immediately called?
I can guess answers to those questions, but I don't know. The only
way to know is to look at real code.
Thanks.
Ian