$ go version
go version go1.6 windows/386

$ go env
set GOARCH=386
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=386
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Documents and Settings\Dmitri\Dmitri\GoLand
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_386
set GO15VENDOREXPERIMENT=1
set CC=gcc
set GOGCCFLAGS=-m32 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1

(For testing purposes only, I don't actually use Windows XP.)

What did you do?

On Windows (or any other OS where os.PathSeparator is not /), I started with a clean GOPATH, and ran the following command two times in a row:

go get -d -u -v golang.org/x/net/context

What did you expect to see?

$ go get -d -u -v golang.org/x/net/context
...
golang.org/x/net (download)

$ go get -d -u -v golang.org/x/net/context
...
golang.org/x/net (download)

What did you see instead?

$ go get -d -u -v golang.org/x/net/context
...
golang.org/x/net (download)

$ go get -d -u -v golang.org/x/net/context
...
golang.org\x\net (download)

Notice the backslashes instead of forward slashes in the second line of output.

(I've snipped irrelevant parts of output with ....)

Cause

It happens in src/cmd/go/get.go#L412. That prints value of rootPath, which comes from one of two paths, depending on src/cmd/go/get.go#L347. The problem is in the top-most path, when rootPath value comes from vcsForDir which contains a bug (it doesn't do what its documentation says it does).

This is a bug that was reported and fixed in golang.org/x/tools/go/vcs.FromDir, an exported copy of that function. It was fixed in golang/tools@5804fef. However, it hasn't yet been backported to cmd/go.

I have a CL that I'll submit now that resolves this issue.