OK, suppose you are writing Google Maps, from scratch. Is the above the first thing you're going to worry about?

Actually yes - you usually start with drawing a tiled raster map, it's way easier than a vector one. A raster map is just a bunch of IMG tags side by side. But let's go with your scenario of vector drawing, it will serve just fine and maybe I'll learn something:

And the "postcondition" is that the canvas should receive drawing commands to display something in the right line style for a road segment, against a background of the right color, at the right scale.

So the test says "calling this code must result in this exact sequence of calls to the underlying API"? Hah. I have a method like this in one of my maps, but as far as I can remember, every time I tweaked it (e.g. to optimize the use of the different canvas abstractions in different browsers - SVG, VML, Canvas) or fixed bugs in it (like MSIE drawing the line off by one pixel when image dimensions have certain values) - I always ended up changing the sequence of API calls, so I'd need to edit the test every time which kinda defeats the purpose. Basically, this kind of postcondition is lousy. If I could express a postcondition in terms of what actually happens on the screen, that would be helpful, but I can't. What does TDD give me here, apart from wasted effort?

Or, that I've heard of, a tiny little IDE called Eclipse?

Eclipse was developed test-first? I never heard of that and that would be very interesting. Do you have any references?