No Stupid Questions

So you're talking about Markdown. It's a specific format, popularized initially on Reddit, that has now become so widely used it is almost universal nowadays (and only growing more popular since so many AI seem to use it natively), and while I agree with you in general and I'd even go as far as to call this a fundamental anachronistic design flaw of Markdown, I think to gain any understanding of this issue you have to understand the historical context that Markdown was born from, and for that you need a history lesson.

Let's start by establishing some terminology: "ASCII" is the most basic standard for computerized text. It's quite limited, 127 characters, ~30 of which are non-printable control characters (including CR). This is pretty much the most universal, most compatible form of transmitting text over the internet. It's built into almost every other standard as its foundation, and we basically can't live without it anymore. We often call it "plain text", although nowadays we also have unicode, or "UTF-8" in its most common form, that would also like to claim that title, even unicode contains those original 127 ASCII characters hardcoded right at its base.

Anything beyond pure ASCII or sometimes unicode typically falls under the umbrella of "rich text". "ANSI" was one of the earliest and most basic forms of rich text, again completely built on top of ASCII, and is still used sometimes for terminals today. It allows some basic colors and bold/underline, occasionally supporting double-width or italic. It's very primitive compared to what we are used to nowadays and it relied heavily on non-printable ASCII control codes to do its work. In the old days, there was no capability for any sort of line-spacing other than 1. if you wanted a paragraph, you typically did TWO newlines to add 1 line of extra space in between the paragraphs to make it clear the previous paragraph had ended and a new one was starting.

The first truly cross-platform "rich text" that came around was "HTML", which is still of course what we use for the web today in all its glory. It wanted to do things differently than ANSI, and in a way, this was so that it could be compatible with ANSI. If you're copy-pasting code out of a terminal and getting a whole bunch of hidden non-printable ASCII that are going to mess up your HTML, that's a problem. This is where the roots of that issue you're seeing in Markdown were born. HTML intentionally has a whitespace-agnostic definition. It intentionally wanted to get away from all those ASCII "non-printable" control codes and it consciously chooses to completely ignore them, crucially, including CR/LF (which have all sorts of their own problems with cross-platform implementations, DOS/Windows uses both CR-LF and sometimes only recognizes both CR-LF in that specific order. Unix ONLY uses CR. Older macs ONLY used LF. It was a mess, and it caused a lot of problems (sometimes still does). HTML got around this entirely by completely ignoring those characters and treating them as if they didn't exist. They can't have cross-platform compatibility issues if they don't do anything in the first place.

HTML instead supports tags that control when to move text to a new line, and just as critically, HTML decided to make a key semantic distinction between "lines" and "paragraphs". specifies a line break ONLY, without breaking the paragraph. specifies a paragraph break, or a paragraph block depending how you use it, and that caused confusion of its own. But like it or not, paragraphs quickly became the standard method of laying out text on the web, and was sidelined as an afterthought.

As HTML and the web as whole grew, HTML started to gain a lot of very advanced and powerful features. Early internet forums wanted to make it easy for novices to communicate in some form of rich text without necessarily knowing HTML, and they didn't want to enable all the advanced features of HTML some of which posed legitimate security or usability risks for the rest of the site especially with javascript and web requests. They created their own forms of tagging like BBcode that they translated into a safe subset of HTML behind the scenes. Again it was typical to use paragraphs here, it was starting to become the expectation for "CR" to mean paragraph. Sometimes, the old typesetting definition of paragraphs was adopted, where two CRs meant a new paragraph, and one CR meant a new line only.

Meanwhile, you've got Microsoft Word and other word processors which are also working natively in rich text and paragraphs, and hitting enter in Word gives you a new paragraph, OR a new line depending on exactly what context you're currently in, but again paragraph is kind of the assumed default.

Finally, Markdown enters the scene. It comes from the world of HTML and BBcode and Word, but it wants to go back to the days of ASCII and make invisible choices of whitespace start mattering again, to get rid of all the ugly tags wrapped around all of our rich text up to this point and make nicely readable plain text where the whitespace defines how it's going to be presented, and its choice to resolve this dilemma is that it decides to keep the historical typesetting distinction of two CRs in a row makes a new paragraph, and it translates that into an HTML paragraph so it's not actually separated by two full lines when you have an HTML rendering of markdown, it's a proper HTML paragraph. So far so good. At this point, they could've chosen to do exactly what you said and what I think would've been the consistent thing to do: one CR (not two) means just a single new line, and sensibly, that would translate to an HTML element and everything would've been lovely.

But they didn't.

Instead, for whatever baffling reason, possibly because Markdown does interpret CR/LF in other formatting contexts like headings and tables, possibly because DOS/Unix/Mac line endings were still a bit of problem even at that time, and like I said was very, very sidelined by the whole culture and history of HTML, but without being able to see into their minds I can't say for sure exactly why they decided to go their own way for the implementation, coming up with this wonky "two spaces after a line" to require people to be deliberate about it. But they obviously continued following the HTML tradition of CR/LF being otherwise ignored.

Not to fully excuse this decision, but in their defense, sometimes copy-paste can insert newlines where you don't want them, so it's not always as clear that a CR is intentional the way you're hoping. Maybe the idea was that these non-spaced CRs aren't necessarily going to be intended if you're often copy-pasting long, wrapped lines out of an 80 column terminal or something. I still don't think that is justifiable, but it is what it is.