It is a double edged sword. The type-kind-rank (TKR) argument matching catches many programmer errors, so relaxing that TKR matching would mean that those types of errors could not be detected at compile time. That is why many legacy codes with explicit interfaces have this error to begin with.
I think we talked about this a little in relation to this thread. Spacing of the results of Fortran intrinsic random_number - #36 by RonShepard The “solution” I ended up adopting there was to use assumed rank argument association, which then requires select rank blocks internally. If there is only one such argument, that isn’t so bad, but if there are many such arguments, and all possible rank matching is required for each of them, then the complexity can grow in an exponential way.
There is a special case that is easy to work around. If the actual argument is scalar x, and the dummy argument is intent(in) :: x(:), then you can change the call statement actual argument to [x]. This rank 1 expression matches the TKR dummy argument. But this doesn’t work with other intent, so it is not really a general solution.