That's great, thanks a lot to Dan for writing it. But it's a very long document, and how would you all prefer to handle feedback, challenges and improvement proposals? While this is probably the most faithful description of the (current) implementation - which is extremely helpful to users of the current version - I'd love to also start a debate on how we should improve it, so a clear distinction between -A cases which match what Infinispan aims to be and therefore people should either live with it or look for a different solution -B cases for which we agree they are a current limitation for which we have hopes to eventually improve on To be clear, I think some of the described semantics are unacceptable in practice, but I'm unsure on what would be the best platform to have such a debate; I'm afraid that by email we'd be focusing on the first raised points first while we should identify priorities, and being this a long document there are going to be lots of items to discuss. It might help a lot to classify A vs B cases to try and define a mission for the project. A selfish example for such a mission sound like "be an efficient and reliable way to store Lucene indexes for Hibernate Search", or "Aim to become the most efficient cache strategy for Hibernate". These are just examples, but would be helpful to define "current known bug" vs "unavoidable limitation". I realize that my very own view of "acceptable limitations" vs. "unacceptable" is defined by these use cases I have in mind. Especially the "key/value store" could use some clarification to see what we're aiming at. Just for the sake of an example, the "limitation" pointed out of when using an Invalidating Cache with a shared cachestore, that invalidated entries might return from the cachestore seems a critical concern to me. But again thanks a lot for writing this, great step in the always challenging direction of improvement! Sanne On 23 December 2014 at 13:38, Bela Ban <bban(a)redhat.com&gt; wrote: