TIL that having a mono repo in Go is totally doable, and perhaps preferable. I was missing that tags can begin with the path to the module nested within the repo and potentially another module so that Go resolves the tagged versions of these modules as if they were in their own git repos (which would just have the semver tags only without the prefix).
I did git a snag, however, with go mod tidy not working because it could not find latest on the nested modules. The fix is to tag the committed code with a -beta.N suffix to enable them to be found. This allows others building your project while working on a PR affecting multiple modules to continue to have their code work. Moreover, they are less likely to break because each of the modules is locked in their own dependency graph that they have to explicitly choose to update. This frees me to develop on modules within the same repo rather quickly without fear of breaking people working with the new stuff as I work with it.
It’s important to note that go work is great but completely ignored by go mod tidy.
It seems that most projects that do this opt for each module within the same single git repo to be at the top level so that the import lines are pretty.