ah neat -- I also tried to fix this but in a different way (with a lot less churn in the error messages maybe?)

commit b451101791055aa88b26b8be417e2cce3d912630
Author: anthony sottile <[email protected]>
Date:   Sat May 3 12:19:14 2025 -0400

    produce error when passing a named argument to a vararg

diff --git a/mypy/argmap.py b/mypy/argmap.py
index a1c4ef72e..28fad1f09 100644
--- a/mypy/argmap.py
+++ b/mypy/argmap.py
@@ -78,7 +78,7 @@ def map_actuals_to_formals(
         elif actual_kind.is_named():
             assert actual_names is not None, "Internal error: named kinds without names given"
             name = actual_names[ai]
-            if name in formal_names:
+            if name in formal_names and formal_kinds[formal_names.index(name)] != nodes.ARG_STAR:
                 formal_to_actual[formal_names.index(name)].append(ai)
             elif nodes.ARG_STAR2 in formal_kinds:
                 formal_to_actual[formal_kinds.index(nodes.ARG_STAR2)].append(ai)
diff --git a/test-data/unit/check-varargs.test b/test-data/unit/check-varargs.test
index 65bbd8456..ec6d4a19c 100644
--- a/test-data/unit/check-varargs.test
+++ b/test-data/unit/check-varargs.test
@@ -145,6 +145,11 @@ f(*it1, 1, *it2, 2)  # E: Argument 3 to "f" has incompatible type "*Tuple[str]";
 f(*it1, '') # E: Argument 2 to "f" has incompatible type "str"; expected "int"
 [builtins fixtures/for.pyi]
 
+[case testCallVarArgsWithMatchingNamedArgument]
+def f(*x: int) -> None: pass  # N: "f" defined here
+f(x=1)  # E: Unexpected keyword argument "x" for "f"
+[builtins fixtures/for.pyi]
+
 
 -- Calling varargs function + type inference
 -- -----------------------------------------

ah neat -- I also tried to fix this but in a different way (with a lot less churn in the error messages maybe?)

Yeah that's also an approach, I figured solving this at a lower level (i.e. parsing) would be better because it would solve more related issues like, well I can't think of any so maybe the error churn isn't worth it.

(sorry I included an issue that diff would fix)

I like your approach better -- though it would be nice if there were symmetry in the error message (*Any, **Any) in a few places but shrugs!

Looks great! To remove the significant errors change, perhaps just handle that in formatting logic (mypy.messages.format_callable_args)? IMO showing the vararg name is helpful for humans, *Any is less clear than *constraints: Any. That part shouldn't be hot, we only format callables in error messages, so another case shouldn't harm.

The bug itself is rather scary, I'm surprised we didn't have any such snippet in the test suite. Please try to get this into the next release!

To remove the significant errors change, perhaps just handle that in formatting logic

Well this change completely removes any knowledge mypy has of the name, so.... to avoid this, I could use @asottile's approach.

it would be nice if there were symmetry in the error message (*Any, **Any) in a few places but shrugs!

I agree. (plus kwarg name doesn't matter either)

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅