Before the pointer passing rules (https://pkg.go.dev/cmd/cgo#hdr-Passing_pointers) were updated for pinning, Go code was forbidden from writing Go pointers (including pointers like *C.x) to C memory. With pinning, this is no longer explicitly stated, but only implied by an implementation note at the bottom of the section:

Note: the current implementation has a bug. While Go code is permitted to write nil or a C pointer (but not a Go pointer) to C memory, the current implementation may sometimes cause a runtime error if the contents of the C memory appear to be a Go pointer. Therefore, avoid passing uninitialized C memory to Go code if the Go code is going to store pointer values in it. Zero out the memory in C before passing it to Go.

Given that pinning exists, I don't think it's unreasonable to allow Go code to write Go pointers to C memory, but more thought needs to be given as to what restrictions that places on the GC implementation. (Note that C code can write pinned Go pointers to C memory.)

This is further confused by the fact that this implementation note still applies. (Specifically, it's referring to the deletion part of the write barrier. If there's a Go-heap-pointer-looking value that's being deleted by a write to C memory, then the GC will get confused.)

This issue was created in the context of https://groups.google.com/g/golang-nuts/c/_7bUuHX0ca4.