OK, I have revisited that example.
When I write a piece of text and expect other people to read it, I have no idea about the size of their screen. It could be as small as a smartphone and only a few words would fit in a line. An other user might use a tablet, a third one might have a very large screen with 4000 pixels. As the author, I have no control over that. Even if someone would quote our discussion on a piece of paper or carve into stone, he or she would wrap the sentences or even break words to fit them into that environment.
Until the original text has a line break.
I have used for sure more than 100 different vievers and editors in my life. From the terminal editor vi to MS Word. I haven’t seen a single viewer or editor, which is not able to wrap the text to fit to the screen or window size.
For this reason, it is not wise to press the return key somewhere in the middle of a text just to enforce a linebreak after 80 characters in the editor that I am using right now. I never do. I only press Return when I have a reason. E.g. the Address or poem.
If the intend is to have a paragraph, then the solution is to have the long line. There is nothing wrong with the long line. The viewer deals with the best fit. Apart from the very new markdown editors on the market, from all the editors I have never seen one, that thinks for me your way and removes the linebreaks, which I have entered by intention.
We may like it or not, but MS Word is probably the most used editor on the planet. It doesn’t remove any line breaks when I paste some text and this is what people are very well used to. This is definitly the largest user base. And even the stone age vi (which I still use, where appropriate), the behaviour is the same. For good reasons. The editor should not change my decisions. It has to work for me, not against me.
The same applies to markdown.
In other words, the solution you asked for in that example is simply not to use hard wrapped text in the first place.
Imagine markdown would be by miracle so popular that half of the text world-wide would be formatted this way, there would be still the other half displayed in other software and would be terrible with all these strange bakslashes and invisible spaces. Copy and paste would become a pain.
Again, there is nothing wrong with one long line. It looks best and works best with all software I have ever seen without line breaks within a paragraph of fluid text. It is and shall remain flexible.
However, there is something wrong with software, which reverses my decisions and removes the hard wrapped lines where I had inserted them by intention. It is wrong if the software removes my freedom and dictates me what is right and what is wrong.
Now one might say, what about all the text out there, which has already those line breaks. The ones, which you are concerned about, which is fair to be concerned about. Let’s repeat your example. First the input:
The overriding design goal for Markdown's formatting syntax is to make
it as readable as possible. The idea is that a Markdown-formatted
document should be publishable as-is, as plain text, without looking
like it's been marked up with tags or formatting instructions. While
Markdown's syntax has been influenced by several existing text-to-HTML
filters, the single biggest source of inspiration for Markdown's
syntax is the format of plain text email.
And now, the way it would look like after a markdown transformation in the way I propose:
The overriding design goal for Markdown's formatting syntax is to make
it as readable as possible. The idea is that a Markdown-formatted
document should be publishable as-is, as plain text, without looking
like it's been marked up with tags or formatting instructions. While
Markdown's syntax has been influenced by several existing text-to-HTML
filters, the single biggest source of inspiration for Markdown's
syntax is the format of plain text email.
Is there a difference?
No
Is that bad?
No
Does that break anything?
No