CL 74790043 - which requires Windows XP - does fix the spurious problems we've been seeing on the windows-386 builder, and it cleans up the runtime (7 #ifdefs removed!), and the discussion on golang-nuts raised no compelling reason we need to keep Windows 2000 support, so Go 1.3 will include this CL and remove support for Windows 2000.
I do realize that a few people spoke up saying that they use or prefer Windows 2000, but we have to draw a line somewhere, there are very few potential users on that side of the line, and the available Windows 2000 expertise we developers can draw on is near zero and shrinking. The simplifications and fixes made possible in the runtime by assuming Windows XP outweigh the few potential uses. Go 1.2.1 will of course continue to run as well as it does today (I think it has the same latent bugs but if you're not seeing them, you probably won't start seeing them.)
The discussion also raised a comparison with Plan 9, which I think is an interesting one. When there are mysterious problems on Plan 9, the source code is available for consultation, we have Plan 9 experts available to answer questions, and, in at least one instance, Plan 9 has been changed to aid Go's implementation. None of this is true of Windows 2000.
I know some people have volunteered to run a Windows 2000 builder and to keep maintaining the code. If you are serious about that, I suggest that you create a public hg clone with the Windows 2000 changes and point people at that. However, if you are thinking about doing this, I would caution that I think the problem is harder than you might realize and the payoff smaller. There may be more impactful ways to spend your time.
Thanks.
Russ