This issue is not about how to resolve this manually, which I know how to do. Rather, it would be better to not to have to resolve manually, but more importantly would better if others did not encounter follow-on issues due to this behavior. Also, in some cases go mod tidy or similar can let someone be "lucky" and not notice this, but in some cases the version information converted by go mod init is important to avoid follow-on issues.
This was a less significant problem early in the history of modules because not many v2+ packages had adopted modules yet.
However, more v2+ dependencies are adopting go.mod files themselves as modules move towards being on by default in 1.13.
I have seen this behavior be the root cause of hard-to-diagnose problems in the wild, and the rate of those problems likely would increase with more v2+ modules in the ecosystem. (And then later, this problem rate of course would decrease, given it is transitional in nature).
This is related to #30161, but that suggested an alternative solution of dropping the dependency during the conversion process, and that issue was ultimately closed by the reporter after the current behavior was explained and the reporter understood how to manually work around. However, ideally go mod init would record the right information here without the need for someone to read documentation or manually work around.