The solution I've found to the "package main" problem is to put the "main" as a sub package.
-src-myapp-main1
\shared_code
\main2
That way main can import "myapp/shared_code". Yes, the packaging standard is being broken for the main programs, but that's ok, nothing needs to import them.
Maybe I missed it, but I didn't find anything on http://golang.org/doc/code.html#PackagePaths that seems to forbid what you're doing. In fact, it says "in practice you can choose any arbitrary path name, as long as it is unique to the standard library and greater Go ecosystem." But rather than main1 and main2, surely it makes sense to name those directories after the binaries you're building?
I actually kind of like Go's scheme here. One thing I never quite liked in C/C++ was huge directories full of source files where it wasn't clear what code was part of what binaries. If something is only part of one binary, why not make that obvious by putting it in another package?
