I'm not denying that for a moment. Perhaps I should have been more specific in what said but I thought my meaning was obvious.
What I meant is that there is no agreed method of converting or moving text from one source (editor, WP, etc.) to another. This means that unless great care is taken then entropy will increase with a transfer, simply information is lost in the process (as in this instance/example), and there are any number of similar cases.
This is a huge ongoing problem that remains to be addressed. Converting text from one environment to another usually increases entropy as information is lost, it's an intrinsic problem by design (or more aptly the lack thereof). Just changing the typeface alone will do that as likey the author of the text relied on some characteristic of the typeface to convey meaning.
A simplistic example is where say a superscript is converted into a normal character during conversion, for example, 2(^2) is 4 and not 22 as is so often the case after conversion. Mathematical equations are notoriously difficult, have you noticed how often they are converted to GIF images or that they require the JavaScript to display them (turn off JS on a typical webpage with math and it'll look like gibberish—and this is despite the existence of MathML which would largely solve the problem. Why isn't MathML used? Because people can't vw damn-well bothered to take the minusculely short time to learn it.
Nothing is much worse than the current state of OCR, with OCR accurate conversions are almost impossible, it's inevitable that we get loss of information through 'read' (comprehension errors through lack of recognition), typeface and text size errors and page layout errors—it's a diabolical mess, a first-class shambles. Want some quintessential examples? Just go to the Internet Archive and look at PDFs with embedded texts, almost every one is diabolically bad, hardly a paragraph goes by without errors. On performance, and after some 40 or so years OCR is still not fit for purpose without major human intervention (hopefully AI will rectify that).
And I put much of the reason for this this down to the indifference of technical people, mainly programmers, who are only interested in transliterating the text character by character, in effect they've SFA interest in other information texts convey, essentially they've no concern that this other information is lost. If it had been just left up to most of them we'd still be using Courier New or System typeface. Want evidence, then just look at the internet RFC specifications.
Thus, it's little wonder that even the simplest case of moving texts between editos/WPs hasn't been resolved after about 70 years of computing development.
Let's go to a slightly more complex matter but still a practical example: I used to use typewriters and it was dead easy to enter text between lines (for corrections, notes, etc. including handwritten comments) by manually turning the platen (platten if you prefer) by half a line or to any degree desired. Come OCR (or any similar schema), and any such conversation becomes one hell of a mess. For starters, can you name any editors or wordprocessors that allow information to be entered into a fraction of a CR/LF (carriage return/line feed)? If you know of any outside of say very specialist DTP stuff then let me know.
The fact is there's precious little being done about the problem specifically for reasons I've mentioned.
I haven't yet read Butterick's book. I was tempted to buy it the first time I visited his site but didn't. From what you say, it's time I did so.
This has nothing to do with typewriters; the text is actually lower case, it's just being used with the small-caps variant of the typeface (I haven't directly verified it, but I am familiar with Butterick's site, and he uses them frequently). It's not really a Unicode problem either; small caps are not encoded in Unicode (well there's something similar for use in phonetic representation but it doesn't have the X for example).
I agree with the other points; keyboards (with the possible exception of handmade ones) have all standardized to a quite limited range of input keys, all traceable back to typewriters, leading to most people I know irl replacing curly quotes with straight quotes, all the dashes with just hyphens, and so on.
In his book, Bringhurst brings up this limitation of modern keyboards, and muses over the possibility of a fully programmable keyboard (in hardware and key displays, not just layers or software hacks like OS/environment-dependent modifier keys). It would be nice to press a button or two and have any keyboard layout I want, multiple scripts, and so on.