Others have made good responses, I'll just add some notes from perhaps a
slightly different perspective.
Language design is always a series of tradeoffs. Every change has both
benefits and drawbacks. As much as possible, the choices made for Go
have been biased toward actually writing programs rather than following
any particular theory of language design.
1) The Uniform Access Principle is a theory about how languages should
work. Is it a good idea in general? I don't know. Is it a good idea
for Go? No. The benefit is that the user of a type doesn't have to
care how some data is implemented. The drawback is that in real
programs, it matters. Go of course permits you to apply the UAP to your
own types, by always using methods. But it does not require you to do
so. If your framework will benefit from providing consistent access to
all fields, then implement them using a method.
2) Go in general permits immutable structs: don't export the struct,
don't export its fields, provide methods to retrieve values but not
change them. For example, the reflect.Value type works this way. The
trick with immutability is keeping it out of the type system.
3) Optional and default arguments would interact poorly with interfaces.
So would overloading. It's very simple and efficient that interface
methods are recognized only by name. Changing that property would make
the language significantly more complex and hard to understand. Named
function arguments could be implemented by requiring that methods match
not only on type, but also on the argument name. I don't know how
useful that would be. Many people implement a similar idea by using a
struct to hold the arguments.
4) Unused errors. One of the issues with writing large programs is
eliminating cruft. Go keeps cruft down by design. It's a tradeoff.
5) Goroutine locals don't really make sense when goroutines are cheap.
6) I'm not sure how I feel about weak references. Perhaps there would
be a reasonable way to add them. I don't think they should go into the
type system, though. And to be useful they should really go into slices
and maps, but then the complexity increases.
7) I think your polymorphism code should simply be designed differently
in Go. Use interfaces for common functionality. Use embedding for
shared implementation. Don't combine them--they aren't the same thing
in Go, although they are the same in C++.