Diagnosis is right and the bug is live. On current v8, module shapes on L6 is reported as L1 and compute_volume() on L9 as L4, so cpp -P is still mislocating every symbol in a capital-F file.

The problem is that the change does not currently do what it says it does, and it needs a rebase.

v8 has moved _cpp_preprocess on since this branch was cut: #include directives are stripped and the sanitized source is fed to cpp on stdin, to close the arbitrary-read vector. That is what the diff conflicts with (fortran.py, test_cpp_preprocess.py, test_languages.py).

Once resolved onto that version, the linemarker mapping turns out to be dead code. With stdin input cpp emits # 1 "<stdin>", and _strip_linemarkers compares the decoded marker path against str(path.resolve()), so in_target is False on every row and line_map comes back all zeros. _orig_line then falls through to the preprocessed line. I checked this directly against a rebuilt merge: the map comes back [0, 0, ...] while the reported locations are still correct, because dropping -P alone is enough to make cpp preserve the line count.

So the fix works, but by dropping -P rather than by the machinery, and the mapping is silently inert as shipped against v8. That matters because the linemarkers are precisely what is supposed to rescue a line-count-changing case, and right now nothing exercises that path.

Could you rebase onto v8 and pick one of:

• match the stdin filename too (<stdin>, -) so the map is actually populated, or
• drop _strip_linemarkers / _orig_line entirely and state in the comment that line preservation now comes from not passing -P.

Either is fine, I just do not want the second option to look like it is doing something it is not.

Also the CHANGELOG entry lands under ## 0.9.24 (2026-07-22), already released, so it needs the unreleased heading.