Ideally, we should go back to a v0.1.1 and c v.1.0, but to achieve this we should track the history somehow

In the typical case you can just check out the previous go.mod from version control, right?

It gets to be more of a problem when you're upgrading and downgrading a bunch of unrelated dependencies in the same change, but that seems easy to avoid: how big is this problem in practice?
(Concrete examples of workflows that can lead to this kind of problem would be helpful.)

$ cd `mktemp -d`
$ git clone https://github.com/mwf/vgo-modules .
$ cd c_user

c_user$ go list -m all
go: finding github.com/mwf/vgo-modules/c v0.1.0
github.com/mwf/vgo-modules/c_user
github.com/mwf/vgo-modules/a v0.1.0
github.com/mwf/vgo-modules/c v0.1.0

c_user$ go get github.com/mwf/vgo-modules/c@v0.2.0
go: finding github.com/mwf/vgo-modules/c v0.2.0
go: finding github.com/mwf/vgo-modules/a v0.2.0
go: downloading github.com/mwf/vgo-modules/c v0.2.0
go: downloading github.com/mwf/vgo-modules/a v0.2.0

c_user$ go list -m all
github.com/mwf/vgo-modules/c_user
github.com/mwf/vgo-modules/a v0.2.0
github.com/mwf/vgo-modules/c v0.2.0

c_user$ git checkout HEAD go.mod

c_user$ go list -m all
github.com/mwf/vgo-modules/c_user
github.com/mwf/vgo-modules/a v0.1.0
github.com/mwf/vgo-modules/c v0.1.0

VCS checkout is great, but it helps only in trivial case when you update, run tests and determine the failure. Then you rollback with VCS and you're done.

But imagine more complex situation, when the bug is hidden - either it's not covered with tests properly or it's just too complex and happens in some particular circumstances in runtime. With a panic for example or even some slow goroutine or file descriptor leak.

So the gap between updating the go.mod and getting the bug could be hours-days. And even several application releases could happen in this time, with other dependency upgrades possible.

Imagine this bug is in production and all you want in this minute is a quick hotfix. You may try to use the VCS, checkout the dependency version from that commit and just take it.
But I bet it could be a hard task if this dependency has a big transitive dependency tree like https://github.com/coreos/etcd for example.

So in case of VCS checkout you will have to doublecheck the transitive dependencies in go.mod after go mod -sync.
I would prefer instead if go get <rollbacked version> does this job for me and takes precisely the transitive dependencies from the previous version, which were stably used.

And the current behaviour doesn't match with doc from go help module-get saying

Similarly, downgrading one dependency may
require downgrading other dependenceis, and 'go get' does
this automatically as well.

It doesn't downgrade the other dependencies now actually.

PS There is a typo in the docs :) dependenceis -> dependencies

I would prefer instead if go get <rollbacked version> does this job for me and takes precisely the transitive dependencies from the previous version, which were stably used.

Rolling back to a previous state is conceptually very different from go get. go get means “make the minimal change necessary to get to the requested version”, not “return me to a point in history in which I depended on that version”.

The go tool is not a version control system. It interprets the current contents of your go.mod file, not its complete history.

This is working as designed, as intended, and as documented: go get means make the exact, unique minimum number changes to effect that command, nothing more, nothing less. You are asking for go get to magically infer the "more" you want. That's just not possible.

You are asking for version control on go.mod. The go.mod file has been engineered to be version control-friendly, precisely so that job can be reasonably done with your version control system of choice, instead of having the go command reimplement a new version control system of its own.

Sorry, I know this is not the answer you want.