I'll bite.

- Ouch!

OS kernels 
Device drivers 
Image processing 
Genetics applications 
Natural language processing 
Cryptography
[download]

All of these can be, and I believe have been, successfully analysed and designed using OOD techniques. Examples:

• The Mach Kernel

  Mach provides a small set of abstractions that have been designed to be both simple and powerful.

• Devices as Objects

  Devices make good objects. Programmers seem to understand and respond well to this technique. As an example, a uCR library includes classes for communicating with a host through a PCI bus.

• GD

  1. To create a new, empty image, send a new() message to GD::Image, passing it the width and height of the image you want to create. An image object will be returned.

• bioperl;

  Bioperl Bio::Root::Root Object
  All objects in Bioperl (but for interfaces) inherit from the Bio::Root::Root.

That leaves

Quickie sys-admin scripts

Good design takes time. Quickies are rarely well designed, they simply get the job done, but if the quickie need to be frequently re-used with small changes...

Would you care to state examples that are intractable to non-OO solutions?

Math.

When you invoke the 'add' method (often overloaded to the symbol '+') on a variable (object) that happens to be an integer, the cpu processes that operation as an integer. If the object that is the subject of that method happens to be a IEEE representation of a floating point value, then the cpu hands that method off to a math co-processor. Try 'add' on a string and you'll get an exception. This is true, regardless of the processor or the language used.

Some languages happen to overload the symbol '+' to perform a concatenation operation on a string, and that too is a OO concept (overloading). However, as was pointed out in these halls not too long ago, that is a pretty bad idea. The semantics of concatenation and those of numeric addition are completely different. 1 + 3 and 3 + 1 are commutative, but "foo" concat "bar" and "bar" concat "foo" are not.

This battle of wits you propose would be a two way street.

As I tried to indicate in my post, I was simply looking for good, well-defined examples of problems that are, or seem to be intractable to OOD, purely for research purposes.

Too many OOD books and courses concentrate on design problems, often concocted or artificially simplified, that naturally lend themselves to OOD. If your going to explore the real benefits (or otherwise) of a subject, it is better to start with difficult examples. If you can solve the difficult ones and show benefits, then the easy natural ones speak for themselves. This was the purpose of my request.