I'd recommend reporting both: keep the logical record number and add a start-end physical line range. When the record occupies a single physical line, simply display line N instead of a range.

csv.reader.line_num reports the number of physical lines consumed so far. For multiline records, this points to the line where the record ends. While that is useful, reporting only the ending line can make it difficult to locate the actual problem.

Consider this synthetic example:

id,note
1,"first entry
2,second entry
3,third entry

The quoted field is never closed, so the reader may consume everything through EOF as part of one record. An error reported at line 4 would send someone to 3,third entry, which looks perfectly normal on its own. The actual problem is the opening quote on line 2.

Reporting record 2, lines 2-4 provides the full context and makes the issue easier to investigate.

A second example is a multiline record with an incorrect field count:

id,note,tag
1,ok,a
2,"line one
line two",b,extra
3,ok,c

Here, the third logical record occupies physical lines 3-4 but contains four fields instead of the expected three.

An error such as:

synthetic-invalid.csv: record 3, lines 3-4: field count mismatch

is more informative than simply reporting record 3, line 4.

Why I would keep both:

• The logical record number identifies the record's position in the CSV data.
• The physical line range helps users locate the problematic text directly in editors, terminal output, or Git diffs.
• Keeping both avoids forcing users to translate between CSV records and physical lines.
• Using line N for single-line records keeps the output concise.

Implementation considerations:

1. Capture the starting physical line before reading each record and the ending line immediately after reading it. For example:

start_line = reader.line_num + 1

try:
    row = next(reader)
except StopIteration:
    break

end_line = reader.line_num

2. Open the file with newline='' when using Python's CSV module, as recommended by the standard library.

3. Consider including structured information in the JSON error response, such as record, line_start, line_end, expected_fields, and got_fields. This allows other tools to consume the error without parsing its message.

4. Handle malformed CSV quoting separately from field-count mismatches. In particular, an unterminated quoted field should ideally produce an error such as unterminated quoted field starting at line 2, rather than suggesting that the only problem is an incorrect field count.

Overall, I think adding the physical line range is worth the small increase in message length. Keeping the logical record number alongside it provides useful context while making multiline CSV errors significantly easier to debug.