Personally I'm a fan of AVR-8 which has 32 8-bit registers so if you want to do 16-bit or 24-bit or 32-bit or 40-bit math you can do it just fine, it just takes longer. The biggest AVR-8 device has about 8k of RAM and about 240k of rewritable program ROM. Those are on different buses so it can suck down an instruction at the same time it transfers data, and clocked at 16 MHz it beats the pants off any of the 8-bit micros of 1980.

You're not going to create really large systems for it, but if you want to work a gas pump or a hot water heater or make a tester for 74xx chips or a display controller for persistence of vision displays it is great.

You can code for it in C but I feel like I'm strangling puppies when I do it because it is moving the stack pointer around and doing things to support C calling conventions that I don't really need for the programs I write [1] AVR-8 assembly is fun but I still write C for it because if I need a bigger device I can recompile it for ESP32 or ARM.

Something weird about AVR-8 is that it does not have a unified address space, so in the case of that display controller, it is easy to spool graphic data out of the ROM, not so easy to upload a small amount into RAM (via serial port) and combine that with data from the ROM. I've had the crazy idea of making a AVR-8 on AVR-8 emulator (would get me to A-rank if not S-rank on AVR-8 assembly) which would make it possible to upload tiny programs into RAM but that probably requires software emulation of unified pointers for program memory.

[1] https://betterembsw.blogspot.com/2014/07/dont-overflow-stack...