I've been reading a lot about caching mechanisms recently and found myself asking this very same question. I can think of only use case (in addition to the ones Leonid mentioned) where it would make sense to store and send multiple ETags
: when a ressource rollbacks.
It could be accidental, such as an api that serves json, and the underlying data gets updated often, in ways that it gets restored to a previous version.
But it could also be by design, where a big configuration object would have only a few different versions possible, that would get switched a lot. (the frequency at which it would be changed is important, otherwise caching wouldn't bring a lot value). In this case, caches would be happy to have all available versions always ready to be served.
I know that's a long shot, and I can't think of any real situation that would fit one of these. Besides, revalidation suck anyway, cache hits are the way to go =)
Also, you might wanna read this. It appears all caches store only the last sent ETag
(which is comprehensible for obvious memory reasons).
Hope this helps