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.
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.
I claim no great expertise in typography but I'm sensitive to both typefaces and to layout, I've been known to not buy a book because its pages are ugly. If the typeface and layout are distracting then I'm constantly reminded of the fact and it slows down my comprehension of the text.
I could spend hours on this but clearly that's not possible so I'll just make a couple of observations. I'm in full agreement with Butterick when he says
"Good typography is measured by how well it reinforces the meaning of the text, not by some abstract scale of merit. Typographic choices that work for one text won’t necessarily work for another. Corollary: good typographers don’t rely on rote solutions. One size never fits all."
For example, I'm a great fan of Garamond and I even use its ligatures but I'd never use the typeface in, say, a letter or email—nor would I use Comic Sans except in the circumstance of an old friend who always uses it in his emails.
Butterick also makes the following points which which I concur but with some qualification:
"Always use curly quotes."
"Compared to straight quotes, curly quotes are more legible on the page and match the other characters better. Therefore, straight quotes should never, ever appear in your documents."
Whilst I agree I rarely use them, and when I do it's when I've selected, say, Garamond for some special task—it would be sacrilege to use straight quotes in such contexts.
Butterick makes the comment that "Most bad habits endemic to digital typography are former typewriter habits†." and this is my reason for mostly using straight quotes. Fact is we've still not fully kicked the typewriter habit yet and our QWERTY keyboards still reflect this by complicating the entry of any character that's not base ASCII despite UTF8 being the commonplace norm these days. We still use plaintext editors like the dreaded Windows Notepad, despite it being Unicode compatible, and so on (as with many text editors, Notepad is nigh on useless when it comes to entering non-ASCII Unicode characters). There's still no agreement on how curly quotes are converted to or cut-&-pasted into or between editors so it's for compatibility reasons I still use straight quotes.
This problem won't be solved anytime soon I reckon, at minimum, it would at least require all plaintext editors to display Markdown and for Markdown or similar to be available in all wordprocessors and there's no agreement on that.
Butterick suggests ways around this by keying in ALT codes and such (and I use them regularly for Greek characters, etc.) but it's far from a universal practice—and that's what's required to make curly quotes universal.
—
† As happenstance would have it this quote appears in Butterick's webpage written thus:
"Most bad habits endemic to digital typography are former TYPEWRITER HABITS".
I cut-&-pasted Buttrick's quote from his website without alteration directly into HN's edit box and the uppercase text was immediately converted to lowercase. I'd not planned this but I could hardly have had a better illustration of the problem than this example.
I hope Butterick actually reads this post, he'll then further appreciate what we're up against—and why people like me insist (for the main part at least) in using straight quotes.