Order isn't guaranteed in \Memcache::get()

This makes sense, I am all for consistency :) Just a couple of things:

+++ b/src/DrupalMemcache.php
@@ -103,6 +103,10 @@ class DrupalMemcache extends DrupalMemcacheBase {
+    $keys = array_intersect_key(array_flip($keys), $cid_results);
+    $cid_results = array_merge($keys, $cid_results);

Instead of doing this why don't we just iterate over the cid lookup array and create the $cid_results return array from that order? We have to iterate anyway..

+++ b/src/DrupalMemcached.php
@@ -71,7 +71,8 @@ class DrupalMemcached extends DrupalMemcacheBase {
+    $null = NULL;

This is not really a NULL, maybe we just call this $cas or something?

jhedstrom, this looks like it also contains the original patch from #2467005: bin gets ignored in cache key unless each bin is declared in settings. Fancy removing that, then we can get this in.

+++ b/src/DrupalMemcache.php
@@ -103,6 +103,10 @@ class DrupalMemcache extends DrupalMemcacheBase {
+    // Order isn't guaranteed, so ensure the return order matches that requested.

1 char over the limit :)

That looks good, but I just had a thought. By this point, the $cid_results has the $cids that were passed into the call rather than the memcache keys. It's quite possible that a cid could just be a numeric value, like an entity ID? If so, array_merge would append instead of replace the values?

We don't have this in core itself, but a custom cache table could easily do that.

Can't we leverage array_intersect_key or so to sort the result by the CIDs?

Like this instead maybe.

EDIT: Doh, forgot the comment from your previous patch!

@dawehner sorry missed your comment there! That is basically what this patch does now. We were thinking the same I guess.