If the replacement path is ./nonexist, then this is working as intended: you could use this approach to slot in experimental subpackages (perhaps named go/types/internal and go/types/generic😁) without modifying the rest of the standard library.
The thing we should diagnose is a module (either the main module or one slotted in by a replace directive) for which the target contains at least one .go source file at the same import path as a standard-library package, which we apparently do not today: https://play.golang.org/p/WMIbECf3o0s
go mod init http is ok, but when I use go mod init sort, Something terrible happened, the VS Code Show me an error.
But it was still good a few days ago. I began to suspect that it was a problem with VS Code, and then a problem with the Go version. Until I reinstalled them all, I even tried to download GoLand to find a solution. Finally I found could‘t use sort. This feels too bad. If all the package names of the standard library cannot be used, I agree. But some work, some don't work, I think this is a bug.