I looked at memcached quite a while ago (seems like 2 years but probably hasn't been that long). My immediate impression was that they needed to get rid of the biggest race condition in their design.

I wrote the authors and they noted that they had gotten the same request (support a revision field in the data and prevent old data from overwriting new data). It appears that they still haven't managed to implement this simple and, IMO, important idea.¹

Without that, I wouldn't use memcached for the more difficult PM caching problems, that is, things that get updated frequently such as the CB.

Of course, adding this to the open source project would probably not be that difficult of a task. And memcached could still be useful for PM without it.

¹ Preventing old data overwriting new data still allows for races, but it is much better and is the best PM will ever do.

memcached should also be fixed to support optimistic locking which can be race-free but any update might fail and have to be presented to a supervisory function (usually the user) to figure out how to handle the failure (and such for PM would suck more than the limited race conditions possible without going to optimistic locking).

To support optimistic locking, memcached would need to allow updates that say "here is the new data and it replaces revision X" and cause the update to fail if revision X isn't the current revision (and do updates atomically, which shouldn't be hard and I think is already the case based on my understanding of their design).

But in any case, memcached is in serious need of a way for it to track revisions (such as a version number like PM's node cache uses or a timestamp -- I'd just support any byte string where a simple 'cmp' determines which is newer and possibly also support variable-length digit strings).