The issue appears to be caused by compNewPixmap. I was under the impression that this function copied the contents of the old pixmap into the new one. However, what it actually does is copy the contents of the *parent window* into the new pixmap. When the parent window is depth 32 and the child pixmap is depth 16, this overruns the pixmap by a factor of 2.

I realize this bug is fixed, but I have to ask if there could be another way to close the security hole. As it is now, what Aaron Plattner said "That would work, though it would be slower." is far beyond true. It's to the point where it's impractical to use any composite aware terminal with compositing on.
Is there any way to avoid using compiz for the case of differing depths, or possibly to set the default depth for all windows to be 32 when compiz is active even if the window is not using all 32 bits?
If need be I can provide more information, but the heart of it is that I remember a time when a composited terminal was faster than non, but now my newer system with much faster graphics (geforce 8800gt vs geforce fx5200) can't display a terminal emulator without lagging... doesn't seem to sit right somehow.
I'd be happy to work on developing a patch, but I'm admittedly new to X11 development, so I wanted to ask you, the experts, whether there's something which can be done before I sink time into it.