Steps to reproduce the issue

On most modern web hosts (I hope) opcache caching is becoming the norm.

In the early days, most people implemented opcache_reset as the "way" to invalidate a sites PHP files from the opcache. There are still a lot of blogs promoting this from the early days of opcache.

However, the documentation states:

opcache_reset - This function resets the entire opcode cache.

This means the ENTIRE SERVER opcache, not just your Joomla site, but all the caches of all the PHP files the running PHP process has a cache for. This, on a shared host, could be hundreds of thousands of PHP files serving hundreds of sites.

Quotes from WordPress 3 years ago:

Under certain PHP configurations, calling opcache_reset will reset the opcache for all users on a given server, or, at the very least, all websites that a given user owns. For example, if a server using PHP-FPM uses a common PHP-FPM master process, despite having separate pools of workers for each worker, calling opcache_reset will reset the opcache for all users on the server using the common PHP-FPM master process. I believe this same behavior occurs when using mod_php (running PHP as a Dynamic Shared Object in Apache) even when using mod_ruid2 or other security modules in Apache

Clearing the opcache for all websites on a server or all websites owned by a single user would likely have a pretty significant impact on performance in terms of traffic that could be served and on website resource usage

There is not a single use of opcache_reset in WordPress 5.7.

Expected result

Joomla is a good neighbour to other sites on a server and doesn't EVER use opcache_reset to avoid invalidating caches that dont belong to this Joomla site.

Actual result

opcache_reset is used at the end of installing plugins and at the end of upgrading Joomla in Joomla 3 and 4

(as well as one use in the phar-stream-wrapper that we have to ignore)