[Animats]

That's why significant end of line whitespace is a terrible design feature. You can't see it. It might get deleted accidentally.

There were some systems back in the DOS/early UNIX era which had significant EOL whitespace. Spaces at the end of a line are still significant following a "\" in shell files. Some early word processors under DOS had significant whitespace at EOL, but tended to display something like a paragraph mark when it mattered.

Python had tab/space trouble at beginnings of lines, but the compiler was finally fixed so that it emits an error if tabs and spaces are mixed in a way which makes indentation visually ambiguous. That was a neat solution to the problem.

Leading tabs in makefiles were a mistake. The author of "make" once wrote that he put that in, and then, the next day, realized it was a bad idea. But he already had a user base of three users and didn't want to change it and break their code.

I thought this idea was dead and buried. Sometimes, they come back.

[Pxtl]

MD could have been fine if it were the beginning of the line. "Any indentation without a blank line above is BR"

It would make multiple repeated BRs difficult, though, but you probably shouldn't be doing that anyways.

[BHSPitMonkey]

For what it's worth, GitHub Flavored Markdown changes this to be more TeXy: any newline in text renders as a <br>, and you add an extra blank line to denote a paragraph break.

[kentonv]

Unfortunately that means that you absolutely need to enable word wrap in your editor, people cat-ing your readme on the shell will see ugly mid-word wraps, etc. Not the end of the world or anything, but somewhat inconvenient.

[Pxtl]

That sounds like a failure of cat more than a failure of markdown. There isn't a command-line argument for cat to break long-lines at the last whitespace of the line instead of mid-word?