Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

empty: Determine whether a variable is considered to be empty.

Returns FALSE if var has a non-empty and non-zero value.

The following things are considered to be empty:

"" (an empty string)
0 (0 as an integer)
0.0 (0 as a float)
"0" (0 as a string)
NULL
FALSE
array() (an empty array)
var $var; (a variable declared, but without a value in a class)

http://www.php.net/manual/en/function.empty.php

The response to this bug is mistaken. The behavior of empty in this case is according to the specification, but the specification contains an incurable inconsistency. Specifically, the documentation of ArrayAccess interface states:

"Interface to provide accessing objects as arrays."

However, the behavior of empty makes this a false statement. ArrayAccess implementors do not behave as arrays with respect to empty and there is no way within the specification to make them do so. One way or another, this is a "bug". Through the various SPL interfaces, Objects can be made to behave as arrays in other respects--- an explicit SPL design intention--- but not this one.

This would be merely a wart and easy to work around except for this critical fact noted by the original submitter:
"This could catch out people who are implementing objects with Countable as array stand-ins."

Given the misbehavior of empty in this respect, there is no way to substitute a 1st-class object for an array in an API without breaking client code. This leads to a fear of making that substitution and therefore to overuse of complex, fragile, multi-dimensional arrays when Objects are the correct implementation choice. The empty Object bug prevents obvious and otherwise compatible refactorings leading to enshrining bad design.

Personally, I find the exhortation to the original submitter to 'read the documentation' to be dismissive and insulting. It is quite clear that he had read the documentation and put work into writing a correct and complete report. That effort should not have been dismissed out-of-hand. There are arguably good reasons not to fix empty and array_key_exists, but the response does not present any such reasons.