Similar ideas have been suggested before. I was not successful at finding the ones I remember seeing, but #19849 is a recent example.

The general idea is that go get should not run arbitrary code. See Brad's reply in the thread above.

I also don't think this proposal is detailed enough. What exactly would you do in such a build.go file that you can't currently do with regular Go files and go generate?

Also note that some projects already use custom build systems like make. You only have to stick to go get (or install, etc) if you want your package to be easily and quickly installable.

I don't think I have the authority to decline proposals, so I'll let someone else decide. But I'm fairly sure this was ruled out in the Go design on purpose.

it is related with golang/dep#269
and it reflects golang/dep#269 (comment)

Blocked on dependency management.

Blocked on dependency management.

Dependency management is essentially done at this point, so removing Proposal-Hold.

This also goes against Go's work in supply chain security: https://go.dev/blog/supply-chain

Building code doesn’t execute it
It is an explicit security design goal of the Go toolchain that neither fetching nor building code will let that code execute, even if it is untrusted and malicious.

As noted by @seankhliao this runs directly against the design of Go's dependency management.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group