I know there is a certain amount of confusion at present about SetFinalizer, but I'm not sure your proposal is strong enough. I think that this program is race free:
http://play.golang.org/p/WdFVb3p7du

In words, if I have a pointer, then the pointer can not be finalized while I'm in the process of using it to assign a value. That is stronger than merely saying that SetFinalizer happens before the execution of the finalizer.

One possibility would be "given a pointer p, any read or write of *p happens before p's finalizer is run." But that is too strong, as it prohibits the compiler from reordering any operation across the use of a pointer.

I feel like what we want here is an inverse relationship. Given a pointer p, there is no possible ordering such that the finalizer happens-before any read or write of *p. But I don't know if that makes any sense.

Moving to unplanned.

One possibility would be "given a pointer p, any read or write of *p happens before p's finalizer is run." But that is too strong, as it prohibits the compiler from reordering any operation across the use of a pointer.

Indeed. Also if you have p.f.foo(), you generally don't know whether you access *p or **p and that can change over time. So a guarantee only for *p becomes too subtle to be used reliably. I also suspect there are more optimizations it prohibits as it effectively makes almost any store a synchronization operation. Also, if I just load from an object, but they result is eventually unused, does it order finalizer?

FWIW Java makes exactly the guarantee I described.

I feel like what we want here is an inverse relationship. Given a pointer p, there is no possible ordering such that the finalizer happens-before any read or write of *p. But I don't know if that makes any sense.

It makes sense, but it states effectively what I proposed :)
If a finalizer can't happen-before, then it happens either after or concurrently. But if it potentially can happen concurrently, then you need to synchronize accesses to prevent data races.