I find the twin 8bit CPU's myth funny as hell. Not only would two 8bit processors working at half the real frequency have less overall CPU resource than the single CPU that's in there now, it would have also been more costly than a single 16bit processor (motorola wasn't the only company with 16bit processors). The idea is ridiculous, really.
And from Sega's blatant advertizing of 16bit graphics for the Genesis, why didn't they extend that to the cpu as being 32bit? From a completely
software perspective, it is a 32bit CPU. Although that's rather pathetic compared to other real 32bit CPUs. The original 68k's used hardware macro instructions, passing the extended operation across the ALU a second time. This saved the cost for fetching and processing an additional instruction which is normally used. This also has the benefit of being forward compatible for when the 68k line advanced to real 32bit ALUs. The 68000 was a very forward thinking design.
I put the TG16/PC-Engine in the 16bit era for consoles. It's just a name after all. The GPU in the TG16 is 16bit through and through. It can only take words via the port, only used word addressing (for vram), only has word size registers. The Genesis VDP by comparison has a single 8bit bus to vram, 8bit bus to the cpu (spreed across multiple ports to accommodate the 68k's word and long word writes, but the addressing messes up for byte increments other than power of 2 - the word gets split into two byte writes to two different locations), 8bit addressing, etc. And the SNES with it'd 8bit data bus for the processor (IIRC twin PPU 8bit data bus to vram, etc). The TG16 cpu is faster than the SNES and is on par with the Genesis. The palette is 512 color like the Genesis (considered a 16bit console by gamer standards), has a much vram as the other two, has a 2megabyte external address range (no mapper needed to access it), has a whopping 32 sixteen color subpalettes of color ram (hence the 482 colors onscreen claim. Compared to Genesis 4 sixteen color subpalettes and SNES 8 sixteen color subpalettes), larger max sprite size than the Genesis (pce = 32x64 max sprite size), sprite scanline bandwidth matches the other two system from that era (width of the screen), both res modes above the normal 256x240 are higher res than both Genesis and SNES (pce has 344 and 512 horizontal res modes), more flexible sprite sizes per screen than the SNES (snes only has two onscreen, PCE can use all 6 sizes), PCE has proper buffering/fifo for h-sync BG X and Y updates per scanline with a proper interrupt support (unlike say the NES and SMS), etc. The PCE has the power and specs that put it in the 16bit era of consoles. Being the first system out of the three, it does have some disadvantages (like only 1 BG layer) but it also has a number of advantages over both the SNES and Genesis too.
If the TG16/PC-Engine is an 8bit system, then the Genesis and SNES '16bit' systems by comparison are rather pathetic in their 16bit-ness
If you put a 16bit processor in the TG16/PCE, nothing
would change. But I guess we wouldn't be having this discussion then, would we? The system has the fortunate (or unfortunate, depending on how you look at it) experience of being on the cusp and so you tend to see a lot of transitional software as a result. Especially if you limit yourself to just hucard games (in ended as the dominant format before half the systems life, to the CD format). I think software enjoyed this style of 8bit and 16bit transition on the PCE and made it as popular as it was in the first few years. It's not until the later half that you start to see more mature (for the time) software taking hold on the system. But unlike, say the Genesis/Megadrive, the PCE wasn't really pushed hardware-wise (exploit the massive subpalettes, near unlimited access to vram during active display for some higher quality animation, etc).