That seems like an unfortunate tool to have discarded. Right now, I can use vertical separation to structure text, but horizontal separation.... Well, that's far more limited.
Within sentences, there's the dash—either em or space-en-space, depending on where you're from—and there are plenty of other structural options. Between sentences, you've got the ellipsis, and that's it. The way they're used in the Declaration, in place of paragraph breaks, is helpful even when you're not just trying to save space—for example, to structure a list of short words or phrases without creating the visual separation from the text that comes with using separate lines.
No, that’s the whole point I’m making. A semicolon is no better than terminal punctuation in creating visual horizontal space, which is a tool for communicating semantic structure, but one that we never use. I am not speaking to what is grammatically proper, but rather to what is possible outside of current accepted usage.
I have no issues with people exercising their personal choices when it comes to the number of spaces after a period. However, I found it to be quite annoying when they began complaining about my preference for a single space and asserting that their method of using two spaces is more correct than mine. Ultimately, I've come to the realization that this is more akin to a matter of personal belief rather than a technicality. It seems nearly impossible to bridge the gap and find a consensus on this issue.
My issue with single-space is that it turns programmatically parsing out sentences from "pretty simple regex on terminating punctuation + (two spaces OR newline)" to "tangled mess of heuristics and corner-cases".
Obviously humans can figure this out easily, so I don't really notice or care if I'm reading something with single-spaced sentences, and it's pretty rare that I need to parse sentences... but the moment that need does arise, I'm gonna end up judging the hell out of that "personal choice" - to say the least.
While I cannot comment on the specific use cases mentioned by the previous person, one example where parsing out sentences can be useful is in the context of Computer Aided Translation (CAT) tools, also known as translation memory. As a software engineer in the field of localization, I encounter this requirement on a daily basis.
In CAT tools, there are well-established heuristics that handle the majority of cases, making sentence parsing relatively problem-free. For the remaining cases, reputable CAT solutions provide features that allow translators to merge or split segments, thus accommodating various sentence structures. As a result, this issue is generally not a significant concern.
It is unreasonable to expect or demand that individuals discard their writing styles solely for the purpose of text processing, especially when both styles are equally prevalent. The blame, if any, lies with the limitations of the language itself for not providing clearer guidelines in this regard.
Most common for me would be keyboard navigation in text editors. Emacs, for example, assumes double-spaced sentences by default when using M-a / M-e / M-k / C-x DEL for sentence-based navigation/editing: https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...
Being able to count sentences per paragraph, words per sentence, etc. is also handy for maintaining good writing style. Excessively-long sentences or paragraphs can be trickier for folks to read; having solid metrics around sentence/paragraph length helps identify candidates for simplification.
It’s not their problem if I stab my eyes out with a pencil when I see two spaces.