Improve strict_types uptake by (optionally) ignoring if called from call_user_func,...

Description

To increase uptake and compatibility strict_types=1 currently already will only apply to function calls from within a file that declares it.

Most PHP applications provide filterables (e.g. WordPress' apply_filters for example), which calls callbacks using call_user_func(. Unfortunately, this means, that any 3rd party code can alter the filterable value/type, which then results in a fatal type error in our code.
Essentially, this resulted in lots of support tickets for us, caused by buggy 3rd party code - which wasn't our fault and we couldn't do anything about - except removing strict_types again from our own code.

https://3v4l.org/PMSFB#v8.4.6

<?php
declare(strict_types=1);

function bad_3rd_partycode( $p ) {
    return null;
}

function my_code( string $path ): string {
    if ( is_file( $path ) ) {
        unlink( $path );
    }
    
    return '';
}

$value = 'foo.log';
$value = call_user_func( 'bad_3rd_partycode', $value );
echo call_user_func( 'my_code', $value );

Fatal error: Uncaught TypeError: my_code(): Argument #1 ($path) must be of type string, null given

This, I assume, is one of the reasons, for the relatively low use of strict_types in non-standalone applications - essentially, you're being punished for someone else's mistakes.

I think it would make sense if either:

1. there was a strict_types=2, that would be essentially like strict_types=0 if a function is called from call_user_func

Pro: explicit and no change for existing code
Con: not backwards compatible with older PHP versions, which means nobody will use it

2. or strict_types=1 would by default ignore strict_types if a function is called from call_user_func (and there is a strict_types=2 added, to keep/enforce the current functionality of strict_types=1)

Pro: fully backwards compatible
Con: makes type checking weaker and requires change of strict_types=1 to strict_types=2 for those who do not want to allow weaker checks - which however, is something that takes 1 min to achieve (just search/replace all files in your code with a simple sed)

I assume this would require an RFC?

Start with the supplied call_user_func example and trace the existing strict_types and callback-call behavior in php-src; the issue names no files or tests. A complete contribution would first settle the proposed strict_types semantics through an RFC, then identify the implementation and regression coverage required.