Fair, if I’m being more careful with my wording, following this requirement would force pyrefly to produce less precise types.
To be clear, if this change lands, I intend to update pyrefly to respect it. For some background, pyrefly followed the overload evaluation section of the spec exactly until this April, when I changed its default behavior because it disagreed with the existing ecosystem in too many places. I also put up a proposed spec change at the time, because the intent was never to deviate from the spec long-term; IMO that’s bad for the type system in all sorts of ways.
I also really don’t want to churn pyrefly’s behavior repeatedly, so I’d like to make sure that we’re really okay with the cost of type checkers following the spec here. If we’re all on the same page, I’m not going to try to block this or anything; this would actually make things easier on me from a maintenance perspective because I could just delete pyrefly’s entire --spec-compliant-overloads flag and replace it with a three-line loop 
Here is an actual example from scipy-stubs, although I’m not sure how illuminating it is.