Adding Any to union should be harmless, I think that's the desired outcome of #18538 (but let's ask @ilevkivskyi to confirm).

However, the error on the last line is really bad - we should not reject func(*Any, arg) if func takes one or more arguments, and so a tuple[correct, length] | Any shouldn't be rejected either.

In other words, this is a bug IMO:

from typing import Any

def report_errors(error_type: int, id_: str, messages: list[str]) -> None:
    pass

any_: Any
messages: list[str]
report_errors(*any_)  # OK
report_errors(*any_, messages)  # E: Too many arguments for "report_errors"  [call-arg]

When there's Any unpacked in the arguments list, it can be something unpacking to the right number of arguments. Since Any is an escape hatch, that should be good enough - we aren't able to prove there's an error. Why do we reject such calls?

Thanks for looking at this, I'd be interested to hear more about what's expected here.

Note that the addition of the Any to the union does also remove the None from it, which is there explicitly in the declaration. That also feels like it would lead to bugs that would have been caught previously.

Even if adding Any to a union is normally ok, it's not clear to me that that is what should be happening here. The intent of the code is to declare an exact type, which is the modified implicitly in a manner which (to me) feels out of step with what happens elsewhere.

Consider for example:

foo: int | None
def bar(): ...

foo = bar()

reveal_type(foo)    # previously: "Union[builtins.int, None]"
                    # now: "Union[builtins.int, Any]"
reveal_type(bar())  # "Any"

foo.bit_length()    # previously: error: Item "None" of "int | None" has no attribute "bit_length"  [union-attr]
                    # now: no error

Which I think is equivalent -- the key thing is that previously the type explicitly declared was respected and this was a way to indicate what the type is locally when we know the return type even if it's not annotated. With the change, Any appears explicitly and replaces None. This seems likely to cause lots of false negatives which would previously have been caught.

This does seem to be specific to the case of the union having None though. Testing with int | str in the above works as I'd expect -- the union remains just int | str throughout and the final line errors as expected.