For what it's worth, my reaction was just the same as Vivek's:
* The behavior of forward-line surprised me;
* The docstring describes that behavior, albeit without IMHO drawing sufficient attention to its oddness;
* The Elisp reference is clearly wrong.
Like Vivek, I'd hesitate to actually change the function's behavior, out of fear that some code somewhere depends on it. But I would like to see the Elisp reference changed, perhaps like this:
diff --git a/doc/lispref/positions.texi b/doc/lispref/positions.texi
index e7c79d5..dde4739 100644
--- a/doc/lispref/positions.texi
+++ b/doc/lispref/positions.texi
@@ -359,6 +359,9 @@ If @code{forward-line} encounters the beginning or end of the buffer (or
of the accessible portion) before finding that many lines, it sets point
there. No error is signaled.
+Perhaps counter-intuitively, if the buffer does not end with a
+newline, the return value is the same as if it did.
+
@code{forward-line} returns the difference between @var{count} and the
number of lines actually moved. If you attempt to move down five lines
from the beginning of a buffer that has only three lines, point stops at