You should prefer not to rename the less-project-specific import because, all else equal, another reader of the code is more likely to me familiar with that package, and thus more likely to understand the original name without further context.

The word “locally” in Effective Go is referring to the name that is used “locally” within the importing source file, not the locality of the package being imported. (It's telling you that some package can be renamed, not indicating which one should be renamed.)

Thanks @bcmills, that makes sense. Appreciate the quick & concise explanation!

Now that you've mentioned:

another reader of the code is more likely to me familiar with that package

It is clearer that it is more so talking about third-party/open-source packages that might be well known. We were looking at imports of our own (private) packages and felt that the opposite made more sense to us when names collide.

For example, we might have 2 packages x.sh/services/user and x.sh/routers/user where the later imports the former. We would typically alias the non-local package in this instance if for no other reason than the majority of code would mostly use the local package and only a few lines would use the non-local one.

Would you say this still a bad idea and the local package should actually be the aliased one?

Would you say this still a bad idea and the local package should actually be the aliased one?

I would say that if one of the colliding packages is closed-source and under your control, you should change the package name instead of renaming it during import.

See https://blog.golang.org/package-names (especially the “Avoid unnecessary package name collisions” part).