For all practical purposes, we probably don't need case-sensitivity here; might just be interesting to know if there was any scenario that necessitated using stripos over strpos when this was first introduced here.

Thanks @ockham! Pinging @artemiomorales @michalczaplinski to double-check this 🙇

Advantages of str_contains():

• more readable, thus understandable.
• less code as it does not need an explicit false check to determine if the substring does not exist.

Some cons:

• it is case-sensitive.
• it is not multibyte safe.

I advise caution in switching false === stripos() to str_contains() for these reasons:

• stripos() is case-insensitive. Thus, when it's used, it may be intentionally designed to deal with case-insensitive edge cases. That may or may not be the case here, but it should cause us to pause to go find out.
• If it usage is by design, then to switch will require a strtolower(), which IMO negates the benefits of switching to str_contains().
• Core is full stripos(), quite common.
• The current code with stripos() was tested. Switching it this late in the cycle should only be done if the change is also well tested with high confidence.

To sum up:
Is there an edge case that could require case-insensitivity? (meaning its usage is by design)

• If yes, close this PR.
• If maybe, wait until there's certainty that there are no edge cases. If there's confidence, then merge this PR; else, wait.

Also noting, this change is not required for 6.4 RC1. It could happen later without effect.

Closing this because it introduces a bug without solving any problems, as it was likely a misunderstanding that led to the proposal.