Ah, but I wonder about how long the client libraries will take to return undef as they timeout if there is no server available, and how they behave if the server gets stuck somehow, accepting connections but not returning results.

I don't understand the problem. Do you think somehow that a memcached client is not robust enough to handle something like that? A database server also can have problems. The clients usually handle it. memcached server and clients are really ready for production. xing uses memcached a lot. facebook uses it afaik. why do you think there could be a connection problem? did somebody tell you about problems?
I was told that if one of the memcached nodes in a cluster "vanishes" - for whatever reason - the client realizes it and reorganizes its distribution of keys then. it can't get worse than now, I'd say.

I've read many articles on memcached, but haven't used it myself. It claims to do failover across multiple memcached servers, but I haven't seen it in action myself, and also what it does when the last server becomes unreachable. I don't know how stable it is, and what the requirements (and administrative overhead) of its users are, and also what its failure modes are.

At PM, we have MySQL behave erratically and grind to a halt from time to time, needing a restart. If memcached also exhibits that ("Just Restart It"), that would introduce yet another slowness problem. And such, I'm wary of enthusiastically following what others claim works for them when I haven't played around with it myself. And I'm looking towards its failure modes because we experience failure modes with MySQL.