The attached patch corrects the treatment of NULL by storing it as-is and using array_key_exists() to test the existence of a key.

As a value returned from wp_cache_get, FALSE is ambiguous. It could mean that the value stored and retrieved was literally FALSE or that the key was not found.

The attached patch moves the found/not-found information to a pass-by-reference parameter, $found, which is set to TRUE after a cache hit or FALSE after a cache miss. This allows storage and retrieval of FALSE without ambiguity and reduces the temptation to use confusing patterns such as !$value, $value === false, and empty( $value ).

What about wp_cache_exists( $key, $group )? No last-resultness or by-ref variable necessary. It would function similar to metadata_exists() and simply return whether the key exists in the group, rather than its actual value.

Also, as long as the reference is declared with the function, and is not call-time pass-by-reference, PHP will not issue a notice here. No $found = null necessary.

Nacin, thanks for the bit about the Notice. I had triggered a notice when the code was written differently. You are correct. I will remove the extra lines from the ticket.

As to wp_cache_exists(), I am extremely reluctant to encourage anyone to check existence separately from fetching the key. Atomicity is important in high-concurrency environments like WordPress.com. If you were to check exists, then do a get, what would be the expected result? With found (internally called last_result) there is less room for ambiguity, race conditions, and errors.

To me, the by-ref sounds like a better solution. It will also allow someone to do $found === true, $found === false, $found === null to determine whether the key was found, it wasn't found, or it hasn't been implemented for the object cache yet, the last one additionally causing a notice. It's elegant, if you ask me.