Aha, interestingly I also ran into this issue this morning, wondering about EOF or what error or when errors are returned.
Thanks for filing the issue, I was planning on filing one on getting back home from work.

FWIW I looked at the code and though about this for a few minutes.

Reader.Read will currently always return (Record, nil) on EOF and (nil, EOF)** on the next call if no other error happens. In fact it will always return either a Record or an error except when FieldsPerRecord is set and doesn't match the colums read.

This could be changed to return a Record (if any) even if there was an error (as with the FieldsPerRecord case) but the current implementation of parseRecord (which is used by Read) only returns a Record and an error if the error is io.EOF, which means the only noticeable change would be that Read could now report (Record, EOF) in addition to (nil, EOF).

I'm in favor of keeping the current implementation and just extending the comment with something like

// If Read encounters the end of the input and the row was not empty,
// it will return the record without an error. Otherwise it will return
// no record and io.EOF.

** Note that this is not necessarily true. I haven't looked at the code of bufio.Reader (which csv.Reader uses), but technically the next error will be whatever the bufio.Reader returns on the next call.

Everything in Go returning (T, error) implicitly means either T is valid, or the error is valid. Only cases where both might be valid (for example, the io.Reader interface) should go out of their way to document something.

But... this thing is called Read like an io.Reader, so it invites some doubt.

So let's clarify. But the way we should clarify is that only one value is ever valid. I just haven't audited the code yet to verify that that's the case. Let's make it true if not.

CL https://golang.org/cl/32172 mentions this issue.