I say this with respect, but I don't think it would. The x86 architecture had an absolute paucity of registers, the mixture of MMIO and PMIO was insane, and it just didn't have any PC-relative addressing modes. Relocation for a flat address space would be an annoyance. Prior to PCs becoming about a billion times faster and the compact encoding coming into its own, x86 code is not fun to write.
Saying "some programs would be difficult to port" is putting it mildly; a huge part of the Amiga's software catalogue was written in assembler, and pretty much every single game wrote directly to the hardware, in a way that can't be abstracted without a complete emulation of that hardware. The Commodore graphics APIs were absolutely too slow to do anything except productivity software. There were retargetable graphics APIs (e.g. CyberGraphX, Picasso 96), introduced to allow well-behaved software to access expensive graphics cards you could buy for big-box Amigas. But generally you wouldn't use them for game graphics (unless it's a very simple game).
The Amiga really held well together; the custom chips were well designed to fit with the 68000. Perhaps too well, and that coupling became the downfall when the computer hardware moved faster than Amiga software could be brought along. It was destroyed once games became more about per-pixel operations (1990s 3D games) than blitting large areas (1980s platform games); the existence of VGA mode 13h made the former so much easier to write. Commodore even added a chip to provide a form of hardware-accelerated chunky-to-planar conversion, but it was too late, only in the CD32 and just couldn't compete with a native chunky framebuffer.
> that coupling became the downfall when the computer hardware moved faster than Amiga software could be brought along.
Both hardware and software moved ahead while Commodore invested in the wrong things. Amiga was late to adopt VGA monitors and PCs quickly surpassed its capabilities. When I mentioned porting AmigaDOS and Intuition to 2/386's, it would be to keep the OS compatible at the C source level as much as possible, with workarounds for hardware when it's different, but always at OS API level so that non-game software (or non-Amiga-like games) could be ported from source.
I don't think it'd have saved Commodore or the Amiga (I think the Sun deal, where Sun would sell 3000/UX boxes was a better bet for that, or maybe not ditching the CBM 900 but, instead, building Amiga with Coherent instead of AmigaDOS).
I don't think most of it was originally implemented in C.
> at OS API level
That's the problem. Keep the original non-protected-memory APIs and you can't have memory protection; add memory protection, and it can't be API-compatible.
Saying "some programs would be difficult to port" is putting it mildly; a huge part of the Amiga's software catalogue was written in assembler, and pretty much every single game wrote directly to the hardware, in a way that can't be abstracted without a complete emulation of that hardware. The Commodore graphics APIs were absolutely too slow to do anything except productivity software. There were retargetable graphics APIs (e.g. CyberGraphX, Picasso 96), introduced to allow well-behaved software to access expensive graphics cards you could buy for big-box Amigas. But generally you wouldn't use them for game graphics (unless it's a very simple game).
The Amiga really held well together; the custom chips were well designed to fit with the 68000. Perhaps too well, and that coupling became the downfall when the computer hardware moved faster than Amiga software could be brought along. It was destroyed once games became more about per-pixel operations (1990s 3D games) than blitting large areas (1980s platform games); the existence of VGA mode 13h made the former so much easier to write. Commodore even added a chip to provide a form of hardware-accelerated chunky-to-planar conversion, but it was too late, only in the CD32 and just couldn't compete with a native chunky framebuffer.