It really wouldn't. Take the average of the puzzle, if it's 75% grey in a wide distribution then move it a bit, repeat until there's some huge change in the histogram. Easier to solve than most I've seen.

Pixels are OR'd, so you'd want 75% grey, not 50% (assuming each of the component images is an even distribution of white and black pixels). Otherwise, yeah.

Good point, I've edited the parent to correct it.

Counting the average size of black-colored connected components would work as well.

Actually it is a terrible CAPTCHA; no normal human will understand why the hell is he supposed to drag those noisy rectangles, while machine will easily find hidden image by scanning and counting entropy.

Yes and no. I'm the inventor of a Google-owned patent (http://www.google.com/patents/US8397275) using N layers of partially transparent images, and JavaScript to generate the offsets between the layers.

The CAPTCHA can be hard to read. (Note that for one of the images in the patent, the lawyer used a Gaussian blur rather than ask me for another screen shot from the prototype.) It might also confuse the user, because they see white noise when the CAPTCHA is first loaded.

The plus side is that it's a simple way to bring JavaScript into the CAPTCHA and force an attacker to create a high fidelity emulation of a browser, hook into a browser, or else take periodic screenshots in hopes of getting the CAPTCHA in its readable state.

Basically, I used to work on JavaScript execution in Google's indexing system, and thought "man, this is a pain to get all of these corner cases just right... how could I force a CAPTCHA attacker to do this?"