Are there any microscopic reasons at all (beyond superstition), to add an extra return after </html> in (X)HTML documents?
Is there any significant reason at all, not to stop this habit of mine? (To me, it looks a lot cleaner with the last line number being the same as the last bit of code, but I'm curious to know if there are any known consequences/possible effects between keeping or not keeping the extra return, such as the last line not being interpreted or something like that.)
It's just superstition. If I remember correctly, one of the earlier IE versions (2 or 3) would throw an error if you didn't have an extra line break there, but I think that hasn't mattered for quite some time.
I don't think there is any good reason. Maybe without the return less data is transmitted so you can save traffic. But I don't think this matters at all ;-)
Nope, like Patrick says it doesn't matter. The entire page can be on one line if you want.
One reason is because some lazily-programmed parsers are programmed to read a line at a time using linefeed or carriage-return-line-feed, and if the data stream just ends then it either won't parse the last line or it will just fail. I have experienced some C compilers and some versions of Make will complain if the last line doesn't contain a linefeed. Obviously these are not HTML, but the reason holds.
I always add an extra linefeed out of habit for this reason.
One thing's for sure, no modern well-known browser is going to care. Indeed in HTML, as opposed to XHTML, the </html> tag is superfluous too.
However, in your first sentence you ask for microscopic reasons and I have one. Some editors (I think notepad used to be one, I haven't checked lately) will automatically add a CR/LF to the last line of a file on save if the line is not empty, probably to fix problems such as the ones DevelopersDevelopersDevelopers describes. This used to be a real irritation when editing DOS batch files as an extra line could adversely affect the way the script terminated.
As a result, if you create your HTML in one editor which doesn't do this, and you don't manually add the final CR/LF, then later someone opens the file in a editor which does, doesn't change anything and saves, you get an erroneous difference that can show up in when searching for real changes or in version control logs.
In your second sentence, you ask for significant reasons. This is not, IMO, a significant reason, and I certainly would bother about such an edge case.
Are you using a VCS? Historically, some version control systems moan about a missing line end at end-of-file; I believe this may be due to diff and patch being (originally) a bit fussy about this.
Not exactly superstition; perhaps we could classify it as an obsolete urban legend (plenty of those in this business).
I always end my files with a linefeed.
At one time I had a automatic tool that would concatenate all JavaScript files in a directory into a single file (to save HTTP requests). This would break if a file didn't end in a newline and also didn't end with a semicolon. Ever since then I've ended files with a newline.
Also, if you use a command line shell like bash, and you cat a file; The new prompt will appear after the last character in the file, so it looks a lot better if that's a newline.