I noticed on the 169.21 forceware drivers that the pixel ownership behavior has changed (Windows XP). In the past, when ReadPixels was called on a partially obscured window a part of the returned data was garbage, but this is no longer the case.
Is this intended behavior, and is it likely to change again in the future? What does the spec say about this (AFAIK it is up to the implementation)?
The spec is very clear about the pixelownership. If the pixelownership fails, data is undefined. Period.
Do not assume anything here. It’s wrong on other implementations, esp. those which share the backbuffer will show this.
That some things got rendered there means nothing. Could simply be that the driver found it to be faster to render than to clip some primitives this time.
Your paint and readback behavior must be the same as for single buffered GDI rendering, there you can’t read stuff from underneath overlapped areas either.
That you actually noticed a difference either means you have a dedicated test for this or something is wrong with your paint or readback assumptions. 
Only FBOs and P-Buffers always pass the pixelownership test.
I cannot find anything straightforward in the spec about ReadPixel and pixel ownership, but it is quite clear in the FAQ section 14.070: http://www.opengl.org/resources/faq/technical/rasterization.htm#rast0060
I think the problem is from pixel ownership when writing to the framebuffer in the first place. The framebuffer is not fully initialized but ReadPixel() report back the full framebuffer.
In the case of writing to the framebuffer the spec is clear:
http://www.opengl.org/registry/doc/glspec21.20061201.pdf
page 202, section 4.1.1 Pixel Ownership Test:
“[…]determine if the pixel in the framebuffer
is currently owned by […] this GL context[…]. If it is not,
the window system decides the fate the incoming fragment. Possible results are that the fragment is discarded or that some subset of the subsequent per-fragment
operations are applied to the fragment.[…]”
Basically, it is up to the implementation and you’d better write code that uses a strategy that doesn’t depend on implementation flavor, as stated in the FAQ.
Many thanks for the clarity, I should have checked the latest spec PDF.
I wasn’t to sure about the FAQ entry as it is probably decade old, and much has since changed (a spec change in this regard wouldn’t break backward compatibility AFAICT, any application relying on the ‘old’ behavior would have been broken anyway).
That you actually noticed a difference either means you have a dedicated test for this or something is wrong with your paint or readback assumptions.
I noticed because I indeed had a test for it. 
I was cleaning up some ugly p-buffer code in an app that I hadn’t run for years. I like the new behavior, but have been burned to many times to make these kinds of assumptions. 
I noticed because I indeed had a test for it.
Nah, waste of time. 
You could get away with it under Vista.
Oh wait, I didn’t say that aloud, did I?
Don’t do that.