It's very arguable whether the behavior of the two should match.

A argument for the current behavior would go like this: in $a = [4 => "hhh"], the key 4.5 doesn't exist, so key_exists should return false; on the other hand $a[4.5] exists and is not null, so isset should return true. There are some problems with this argument, namely that key_exists actually rejects the arguments (it sends a warning) and that there is a very slight mismatch between isset and array dereferencing, but it's just to show this is not a bug (violation of well established specifications), but instead a feature request that merits more discussion.

@Artefacto Yes, I know that it isn't perfectly obvious that the behavior should match. But I'll try to explain why I think so:

a) From the user perspective: What would be a typical application of array_key_exists? Probably it's checking whether a key exists before using it:
    if (array_key_exists($key, $array)) {
        $array[$key];
    }
What would you expect from this code? I would expect that the if is evaluated for every key that $array[$key] won't throw an "Undefined index" notice for.
For example (why I actually opened the bug) Twig does array_key_exists checks when accessing array offsets and people have reported bugs about it throwing errors when used with have whole-number float arguments (like 14.0).

b) From the PHP perspective: It's arguable whether in [4 => "hhh"] the key 4.1 exists or not. I mean, you can access [4 => "hhh"][4.1], so in some way it does exist.

c) We have a precedent: array_key_exists was already modified in the past to support NULL arguments just like isset() does. I don't see why we can't do that for the other argument types.

+1

The only times when I'd want to use array_key_exists() is when I can't use isset() because it returns FALSE for NULL values.

This has been fixed in PHP 8.0.