Function python_module_file_under_source_root 

pub fn python_module_file_under_source_root(
    spellings: &PythonModuleSpellings,
    importer: &ProjectFile,
    module_fq: &str,
) -> Option<ProjectFile>

The file an absolute module_fq names when it is written against a source root the workspace’s own structure establishes.

Python resolves an absolute import against the sys.path entries the importing program runs with. A workspace states the project root and its packaging roots, and python_import_root names modules from those; it does not state an entry only PYTHONPATH adds – dayu’s dependency/, whose core.lib.common is indexed as dependency.core.lib.common – and a distribution directory holding a same-named package makes the inner package importable under both spellings, so YOLOZU’s rtdetr_pose/rtdetr_pose is indexed as rtdetr_pose.rtdetr_pose.config and written as rtdetr_pose.config (#3506).

A tail match alone is not that evidence: source/realpkg/vendor/api.py ends in vendor/api.py, but under where = ["source"] it is realpkg.vendor.api and nothing else. What establishes a root is the snapshot’s own structure – a packaging manifest that declares it, or a complete __init__.py package chain from it down to the module – and only a candidate whose implied root is established that way binds. PythonModuleSpellings::establishes_source_root is that decision; the candidates it rejects stay visible to the diagnostics as the spellings the workspace does index, which is a resolution gap and not externality.

Uniqueness is required after the same nearest-root narrowing an indexed module gets: two workspace copies of one module are an ambiguity the workspace does not resolve, and choosing between them here would invent a preference it never stated (#3475’s rule, applied to the roots it cannot see).