It seems tricky (and inefficient) to decide which commits affect the submodule: for example, should we count commits that touch README files, or only Go source files?

On top of that, it's not obvious to me that we would gain much by bumping the pseudo-version back by a few commits. Are there cases where this results in a significant semantic change, or is it mostly aesthetic?

It seems tricky (and inefficient) to decide which commits affect the submodule: for example, should we count commits that touch README files, or only Go source files?

I might be missing something here, but is it not as simple of running git log or equivalent with an argument of the subdirectory, per above? By definition therefore it applies to all git-controlled files beneath that subdirectory.

Are there cases where this results in a significant semantic change, or is it mostly aesthetic?

There is no semantic change, but I think it's a more useful/relevant reference for the package author and consumer. Because a quick glance at the commit will then show either what last changed in that submodule.

In general we never run git log to poke around and look for commits. We only use tagged commits, or if someone specifies a commit then we'll look it up directly. But we don't go searching for commits beyond tags. I do not want to redefine "latest" on a subdirectory to have to fetch a git log.

If you want more control over which commits are addressed, I think the answer is to tag them, not make this logic more sophisticated.

I do not want to redefine "latest" on a subdirectory to have to fetch a git log.

Ah, that's the bit I'm missing, thanks.

 If you want more control over which commits are addressed, I think the answer is to tag them, not make this logic more sophisticated

That makes sense, even for pre-releases. Sorry, feels like I missed this as an obvious solution to the problem.