I get what you're saying, but I don't think you've identified the problem correctly: with the proper programming abstractions, it shouldn't matter what the word

I get what you're saying, but I don't think you've identified the problem correctly: with the proper programming abstractions, it shouldn't matter what the word size or byte size of the machine is. The problem with code from that era is that compilers were as anemic as the processors that they ran on, so there was not a lot of room (and experience, as you say) to conceive programming languages that were fully decoupled from the software architecture (someone will come in now and shout LISP). We still have that same problem today when it comes to vector code (and graphics/LLM/tensor processing): the abstractions we use are tightly coupled to the hardware capabilities, which means lots of redesign surrounding the compiler and code structures every time a new hardware iteration comes out. I fully expect that in another 10-20 years, our current approach to vector programming will look as primitive as how we look at system code from 50 years ago. So while Hare may still be able to compile single-issue imperative code 50 years from now, I don't think it's too far left-field to posit that the sequential/imperative paradigm we use now might end up being replaced with different processing/signaling paradigms on both the language design and the processor design front, leaving Hare as nothing but a quaint footnote like B.