go get fetches dependencies, so this is not an issue with go get, anything imported will be fetched.

There is no place to put such resources in the normal Go Workspace, as anything placed in the src/[package] directory gets compiled into the resulting binary and is not accessible or editable from outside.

It's quite possible to put resources into a go pkg folder without causing problems, and those are go gettable along with the code. I don't see the issue here.

Running go get for a package clones the repository at its current HEAD/master/trunk, with no way of specifying a version or commit you might want.

Go get doesn't (yet) get versions of packages, just fetches the master. This is something that's been discussed to death on the mailing list, there are plenty of threads:

https://groups.google.com/forum/#!forum/golang-nuts

Some solutions to that are:

Go get everything once, and then stop using go get (the solution in the article, though he brings workspaces into it too, which is unnecessary) - this is problematic as he points out.

Put all your dependencies into subpackages, frozen at a particular version, I like this solution for now.

Put all your dependencies into your own repo, again frozen at a particular version, and only go get or checkout from there

Use something like gonuts.io to add versioning information (relies on the pkg authors to do this though)

Add versioning to go get to check out versions to a specific path.

It would actually be pretty easy to add version dependencies to Go by adapting the go get source. go get already versions for version of the language by looking for a certain tag, but not versions of the package. You could just check out to a path like src/github.com/jasonroelofs/slartibartfast/1.0/ and use that path for imports. Someone should just go ahead and do it, to see how it works out - if it's popular, people will use it, and eventually it might make its way into the default distribution. The folks at Google just don't seem to see it as a problem so presumably their setup/usage doesn't hit this problem.