Yes indeed, the plan with redis-cluster is to support multi-key operations only if all they keys hash the same (the user can enforce this by using the special key-tags, for instance 1234.{foo} and 4567.{foo} will be guaranteed to hash the same).
So it will be up to the application logic to make sure that all the keys that are required to be used with multi-keys operations will be on the same node.
But what I think is that if one wants to write a really distributed and scalable application that can use already some form of application-level partitioning, or that can will use redis-cluster in the future, the way to go is to just use Redis single-key atomic operations, and try to make the application resistent against minor inconsistencies that can be calculated before hand.
For instance in the email linked in the story we are talking about a very common pattern. Example: for X be put in category Y it's needed to have two sets, one is like X.categories where there is the Y category ID, and one is Y.objects where there is the X object ID. Writing a distributed application that is designed to scale with multiple nodes using redis-cluster or any other solution, the best thing to do is that the application itself is able to deal with the case of Y id being in X and X id not in Y or the contrary.
