> I guess I don't attach the same weight to the CISC/RISC thing you do

I certainly didn't appreciate the impact of CISC vs RISC architecture at the time. I understood the conceptual difference between them at a high level but didn't get why that caused Motorola to decide they couldn't keep scaling beyond the 68060. As a user and fan of 68030 and 040, I just didn't understand why they'd walk away from, arguably, the second most popular flagship computer ISA at the time. And they actually told computer manufacturers that the 68060 would be the end of the 68K line more than a year before 68060 even shipped. I was like, WTF? They weren't even done with the latest, greatest chip when they decided to kill the whole line, orphaning all that fantastic software from ever having any upgrade path to the future.

Only later did I gain a deeper appreciation for the impact. A few key things informed me:

* My high level understanding of CISC vs RISC wasn't complete back then. In the late 80s there was a lot of debate among CPU ISA designers on the relative merits between CISC and RISC - and that even extended to the definitions of the terms (which were fuzzy). A good example is this legendary Comp.Sci Usenet discusson: https://yarchive.net/comp/risc_definition.html. Only when I dove into those debates in the last 10 years did I really start to get the larger picture.

* The part that mattered most between RISC/CISC wasn't that RISC had less instructions than CISC (although it usually did), it was that those instructions were much less complex AND that the addressing modes were much less complex. This meant that, in general, RISC ISAs were easier to decode because instruction and operand length tended to be more fixed. This also had a bunch of other downstream effects generally causing RISC-ish ISAs to be easier to pipeline more deeply, easier to branch predict, easier to speculatively execute, etc. These are all things that enable putting extra gates to work speeding up execution.

* I was a huge fan of the 68K's insanely powerful addressing modes which let savvy assembly language programmers pack huge functionality into fewer instructions with addressing modes like indirection on both the input and output along with setting a bunch of flags and pre/post operations like decrement/increment. Programmers not only called 68K addressing modes powerful but also things like "orthogonal" and even "elegant." But all those varying instruction lengths with up to 14 different addressing modes plus even more optional flags modifying behavior before and/or after also created a complexity explosion for CPU architects trying to implement the most powerful new optimizations. That's one big reason why the 68060 was over a year late coming to market. It was only dual pipeline but even doing that was triggering unexpected avalanches of design complexity.

* Both Intel and Motorola realized the only way to continue increasing performance in the future while maintaining software compatibility with their old CISC ISA was to (basically) make future processors RISC CPUs running an extra hardware layer emulating a CISC ISA. It was both hard and costly in terms of gates and performance. Intel's lead in fab process helped them hide that performance cost and keep showing generational net speed increases as they navigated the transition. Motorola realized they'd probably have a generation or two of CPUs that weren't meaningfully faster until they bridged the gap and were on the other side.

There's a lot more but I'm certainly not a domain expert in CPU design and already summarizing my non-expert understanding of expert debates, so I'll leave it there. But it's pretty fascinating stuff. Both Intel and Moto realized that pure RISC implementations would probably beat them soon. Each company responded differently. Intel made the RISC-emulating-CISC approach to ISA compatibility (broadly speaking) work well enough to survive the transition. Motorola decided it was too risky (probably correctly given their fab technology and corporate resources), and instead chose to break with the past and partner with IBM in moving to Power PC. For Atari, Commodore, Apple et al this was a planetary level asteroid impact. If developers and customers lose all software compatibility with your new products, that makes the choice of moving to your next generation not much different than moving to another platform entirely. Only Apple managed to survive (and even they almost didn't). Arguably, they only treaded water with great design and marketing until saved by the iPod.

I should also mention there was another huge asteroid for vertically integrated non-Wintel computer platforms right behind the CISC/RISC asteroid. In the early to mid 90s Moore's Law scaling was allowing desktop computers to improve rapidly by growing dramatically more complex. It was getting to be more than one company could do to win on each separate front. On the Wintel side, the market solved this complexity by dividing the problem among different ecosystems of companies. One ecosystem would compete to make the CPU and chipset (Intel, NEC, Cyrix, AMD), another would make the OS (Windows/OS/2), another ecosystem would compete to make the best graphics and yet another would compete on sound (Creative, Yamaha, Ensoniq, etc). It would require a truly extraordinary company to compete effectively against all that with a custom vertically integrated computer. There was no way a Commodore or Atari could survive that onslaught. The game changed from company vs company to ecosystem vs ecosystem. And that next asteroid even wiped out stronger, better-capitalized companies that were on pure RISC architectures (Sun, SGI, Apollo, etc).

> But all those varying instruction lengths with up to 14 different addressing modes plus even more optional flags modifying behavior before and/or after also created a complexity explosion for CPU architects trying to implement the most powerful new optimizations

You certainly see the impact of the "don't add too many instructions/flags" style of design even today in things like RISC-V that doesn't even use condition codes (an unexpected source of complexity in ISA spec, since every instruction must define exactly how it affects or does not affect each of several condition codes - RISC-V has none of that), expects you to use instruction fusion in larger implementations and defines "compressed" instructions as a mere shorthand for existing full-length instructions in order to simplify decode. ARM64 has made different choices on all of these things, it will be quite interesting to see how they compare in real-world scenarios at the higher end of performance.)