There are lots of cases that would have to be handled to make this consistent.
new(Foo) and make([]Foo, 10) need handling.
What's returned by

    m := map[int]Foo{}
    x := m[0]

?
or the same question for channel receive, type assertion, etc.

At an even deeper level, what happens in this case:

var g *Foo
// goroutine 1:
g = new(Foo)
// goroutine 2:
p := g
if p != nil { println(p.X) }

This is a data race, of course, so as far as the spec goes we're in uncharted territory. But goroutine 2 might very well observe p.X == 0, a mysterious out-of-the-blue value that objects of type Foo should never contain. This isn't a problem today because all objects are zero-initialized. The GC can zero everything at sweep time and synchronize with all threads so they are guaranteed to see that zeroing. No reader can ever see the contents of the previous life of a recycled object. In contrast, in this proposal there's no cheap way to do that global synchronization because the contents required to initialize the memory are not known at sweep time.

I think that the fact that everything is zero-initialised in Go is a useful feature, which leads to the Go idiom of making sure that the zero value of your struct is actually useful. That's an important idiom we should stick to, so that's why I don't like this proposal very much. Also, it does nothing that can't be done using a constructor function. Therefore I don't think we need a new language feature for this.

@randall77 and @beoran, the proposal doesn't nullify the zero-value aspect of golang. This seems to be a proposal on extending initialization for a default value.

If that is the case, @randall77, you would not see any difference in the new or make setup.
When it comes to initializers, a constructor function could be made sure, but the proposal is for having uniformity to it. The constructor function also can have more behaviour than just initial value, so this is not a complete cross over.

To address issues about consistency:

The proposal ideally would change what the "zero value" (I guess now "default value"?) of a type would be.

type Foo int default 5
slice := make([]Foo, 2) // [5, 5]
var foo [5]Foo // [5,5,5,5,5]
newFoo := new(Foo) // *Foo(5)

var fooMap map[string]Foo
fooMap[""] // 5

var fooChan chan Foo
close(fooChan)
<-fooChan // 5

That's fairly intuitive. I don't have opinions one way or another about this.

Unfortunately it allows for this...

type Bar int
var b = 5

// this is gross
type BarPtr *Bar default &b

var x, y *Bar

*x = 10
// x = *Bar(10), y = *Bar(10)

This is gross. However, the 1st syntax in the proposal would not allow for this since only structs can have default values in that scenario, but it would also mean that all non-structs would not be able to have default values.

Regarding data races, I unfortunately can't think of a way to make it thread-safe off the top of my head. The only way I could think of is building mutexes into certain variable accesses, and that's just... bad.

I think that the fact that everything is zero-initialised in Go is a useful feature, which leads to the Go idiom of making sure that the zero value of your struct is actually useful

Really all this proposal does is make the "zero value" (aka default value) easier to use. What this proposal does is make it much easier to make the default value of a type to be useful, rather than making developers jump through hoops to make the zero value of their type useful.

However, it does make the default value of a type less predictable, it forces you to look at the documentation rather than being able to assume what it is, which is not good.

Also, it does nothing that can't be done using a constructor function.

I was about to say that this was factually correct but missing the point, but it actually isn't factually correct. Constructor functions are unable to control what is emitted from fooMap["unknownKey"] or <-closedChan. Ideally, default values would be able to control this.

I'm not super fond of this proposal myself, and the data race issue doesn't help my take on it. It's just an offshoot of another proposal, and I wouldn't personally mind it in the language

@randall77, racy Go programs can already observe invalid values, such as interfaces whose values are not actually of the associated type.

And, of course, nothing prevents the allocator or collector from zeroing unused memory and anticipating zeroed values in normally-nonzero fields of allocated objects.

Given the problems pointed out by @randall77 and the fact that we rely heavily on zero initialization in Go programs, this proposal seems to introduce more problems than it solves. For instance, a reader of a program could not rely anymore on the fact that a composite literal T{} represents the zero value for that T without inspecting the definition of T. This seems like a fundamental property that we rely on in Go code that would be invalidated with this proposal. The conventional way to get a default value for a T is to call an initialization function, such as newT or makeT.