I'm not sure how accurate this is, but it sounds fairly plausible and
potentially worth recording. This is what Claude said when asked to diagnose the
issue:

>  Simple strings use parse_string_annotation → parse_expression_range which:
>  - Takes the full source code
>  - Properly offsets each parsed node to be at the correct position within the source file
>  - Results in unique, accurate ranges for each node (e.g., 200..208 for Optional, 209..212 for str)
>
>  Complex strings use parse_complex_type_annotation which:
>  - Parses just the concatenated string content: string_expr.value.to_str() (just "Optional[str]" without source context)
>  - Calls relocate_expr(parsed.expr_mut(), string_expr.range())
>  - relocate_expr sets ALL nodes to the SAME range (the entire concatenated expression range)
>  - Results in every node having identical ranges: 472..508 for everything
>
>  This is indeed a bug. The relocate_expr approach breaks symbol resolution because:
>
>  1. The semantic model likely uses ranges to look up bindings
>  2. When all nodes have the same range, it can't differentiate between Optional and str
>  3. This causes resolve_qualified_name to fail, returning ["", "Optional"] instead of ["typing", "Optional"]
>
>  The comment in the code says complex strings "cannot be accurately located" - but that should only prevent fixes from being applied, not prevent diagnostics from being emitted. Both simple and complex annotations have access to the same imports.

so I think it's pointing to the `relocate_expr` call in
`parse_complex_type_annotation` in `crates/ruff_python_parser/src/typing.rs`.
I'm also not sure that we can do much better when parsing the annotation, but we
may be able to work around this later in the process anyway.