Shouldn't that return false, since neither haystack not needle are
ASCII encoded?

It could return false, but that's not the historical behavior apparently :)

This should explain what is going on here: https://3v4l.org/lH2KZ

In PHP 8.1 the ASCII validation is stricter and input code units over 0x80 are considered as illegal. This means that both é and à become ?? after illegal character substitution.

If the desired behavior was to do a raw binary search, then the right encoding to use would be 8bit rather than ASCII.

I think the only open question here is whether we should make this fail in a different way. Generally mbstring operates on the GIGO principle when it comes to input strings that are incorrectly encoded, because validating them would add significant overhead to all operations. In this case we do already validate it due to conversion to UTF-8, so we could always report no match in that case. But  we wouldn't be able to guarantee that behavior either, because a future optimization to skip UTF-8 conversion for single-byte encodings would actually get back to the historical behavior.

Basically, if mb_check_encoding() for an input to an mbstring function returns false, behavior is undefined and is going to change depending on implementation details.

I'm wondering why mb_strrchr() needs to do any validation, but anyway: works for me, let's close if that's fine to you.

It doesn't need to do validation, it just currently happens to be implemented by converting the string to UTF-8 first, because that's necessary for strings encoded in non-self-synchronizing encodings. ASCII isn't one of those and we could skip it there, but right now we don't...