It already does something close to this: That's what the "go tool" command does. It just looks in a special directory (pkg/tool/$GOARCH/) for the binary. I just verified this by copying /bin/date there:

% go tool date
Thu Sep 16 10:37:36 AEST 2021
% 

If you put gomobile into that directory as 'mobile', then you could run go tool mobile. That's not quite what you're asking for, I know, but it would be unwise to introduce a second way to create subcommands.

So maybe what's needed is more policy around the tool directory.

That sounds great but does not entirely address the key of the proposal. The key is that we could drop the go prefix using go command. Assume we updated the go tool's lookup policy, then the existing gomobile and a lot of existing gomycommand and go-mycommand command can only be used via go tool command, which means: go tool gomobile
This seems a little bit stutter.

The existing go tool should continue to serve as internal usage, which is for those commands that are not publically available to users but can only use via go tool ... Isn't it?

The go tool command is nothing more and nothing less than a way to bundle a bunch of other binaries into the Go toolchain without putting them all in your $PATH. I created it when I became nervous about all the go* binaries we were adding to the distribution, polluting the shell path of the installation. There is nothing "internal" about it: it is there to make binaries available.

We could easily change gomobile to be mobile, just as we have done for other binaries in the past.

That is a good argument, it still looks great if we change the proposal to: allow go tool look up commands in $PATH with the prefix go or go-, and forward arguments to them, meaninggomycommand or go-mycommand can be used as go tool mycommand.

Does this change makes the proposal more consistent with the existing approach in go tool?

That's the opposite of what I am suggesting. I am suggesting that we allow things to be added to the tool directory, not that go tool look in $PATH.

Adding a command to the tool directory is a Go-specific change and does not empower any few coming commands, it seems too limited. Every time if we'd like to use a new command, it has to send as a proposal. Hence it does not really allow the community-developed tools to customize the usage of the go command. The gomobile is just one example.

$ ln -s $(whence gorename) $(go env GOTOOLDIR)/rename
$ go tool rename
gorename: precise type-safe renaming of identifiers in Go source code.
[...]

Works just fine with any command you can find.

I don't see what the advantages of putting third party commands under the go namespace are?
And based on experience with other commands that do this, there are often inconsistencies in argument / flag handling which degrades the overall ux compared to if they were understood to be independent commands, as well as having a poorer experience with shell completion functions

A few benefits:

• For daily go command users: customize their own workflow. The benefits are as same as why there is a git-codereview command instead of writing a pure git-based contributor guideline, as git mail, git rebase, and etc. offers exact same feature as git-codereview
• Easy for experimenting go commands. If we decide on introduce a new go subcommand to the official toolchain, then we may lunch it as an external command. For command users, the workflow will be: go install golang.org/x/tools/cmd/goxyz, then use go tool xyz. Whenever in the future we want to promote the external command to the actual distribution, users can migrate from the workflow smoothly: nothing breaks because go install can still install an old one in CI system, but since there is a native command for that, then it is selected with higher priority.

I could see value in this if it meant that running programs via the go tool gave those programs capabilities that they wouldn't otherwise have.

For example, perhaps go would put all of the environment variable values described by go env into the real environment of the child process so that it doesn't need to reimplement logic for choosing default values when they aren't explicitly set.

For another example, on my system where I use goenv, go tool ... searches a Go-version-specific directory for tools, and so in principle this could be a good place to install programs whose behavior is coupled to a particular version of Go so I'd know that go tool foo will always run the appropriate build of foo. (This already works today except that there's no "easy" way to install a new tool into there; I assume that improving this was what others had in mind when discussing potentially using the tools directory as an official extension point.)

I feel much less convinced if the idea is just to make go foo an alias for gofoo or go-foo. I would rather just install and run the program the same way as I install and run other programs, because that's more straightforward, it's clearer what exactly I'm running, and I can more easily rely on features of my shell such as auto-complete.

Unrelatedly, I'd note that putting the extensibility at the top level (directly after go, rather than after some other subcommand like go tool) would make it harder to add new built-in go subcommands in future.

It's an anti-goal to make the go command itself extensible in the way that git is.
Closing as infeasible.

You said "closing" but didn't close it. I'll close it.

This proposal has been declined as infeasible.
— rsc for the proposal review group