I'm not sure why this makes any difference: does it fix your case? To me, the call to error_reporting(E_ALL ^ E_WARNING) is still in effect when the second include runs. I don't see how this change would change any behavior, what do I miss?

Did you have a look at the error handler in Sentry? If it ignores the current error_reporting() level, the issue is there, not in the Kernel class, isn't it?

@nicolas-grekas I've checked: this change alone does not fix my issue. You got the point correctly: the root of the issue is in the way how Sentry handles error_reporting (I've mentioned the PR, so the issues are cross-linked. I've even created a PR for that Sentry issue, so the cure is on the way)) ). I've left the PR open up to your decision, just in case if you feel good about my point of encapsulating the trick into the separate method, which tweaks error_reporting strictly around includes, minimizing possible side-effect of such workaround. In case if not - I wouldn't mind you close the PR and the issue itself.
Anyway thank you for your time, I appreciate your questions, which make me think into the correct direction.

Thanks, I'm going to close then, since the code has no bug and we prefer not changing it when it works as expected.