While this has become obvious in php74, because now a warning is
emitted, that function has been deprecated since php71 (without
warning), so it's perfectly ok/safe to apply for it in phpunit7 (that
officially supports php71-php73).

Plus, of course, this enables some projects, that cannot follow
phpunit support schema 100% all the time, to continue working
with phpunit7 and php74.

Our case, Moodle 3.8, to be released in November 2019, days before
the end of php71 support, will need to support php71 and also php74.
Having an unique phpunit helps a lot, and it seems achievable.

Then, in Moodle 3.9, to be released in May 2020, we'll upgrade
to phpunit8 because that will match 100% out php72 - php74.

So basically, in our May releases, we always match 100% phpunit's
php supported versions, but in our November releases, we usually
require an older phpunit to work with a newer php (that is not bad).