I never actually noticed that behavior of sync.Once, but it doesn't particularly surprise me. I have to wonder what the utility of a function that behaves as proposed would be, though. Relying on panics for regular functionality is rarely a good idea.

How frequent is the need for this? See also https://golang.org/doc/faq#x_in_std

I've always used sync.Once for lazy loading data that could come from anywhere, including via the network.
If the network connection fails, then sync.Once breaks down for my use case.
Ideally, I would like a func (o *Once) Do(f func() error).

Until recently, I had just been panicking in situations where the network connection fails in order to force fit into the current API design - believing that it worked as I had intended. ... only to recently discover that it did not (as per documentation).

... hence the proposal.

But really I don't like panics either. I really would like func (o *Once) Do(f func() error).

I don't think you've fully explained what your intended flow is.
In the current API, once sync.Once.Do returns, all following code can safely assume initialization has run.
With the proposed API, without retries, that invariant is broken, and there's no universal schedule for retries that will work in all cases.

It seems your usecase would be better served by having f handle retries