Reality:
1) Game Developers are not kernel or OS developers, there's no purpose to your pretending they are.
2) Actually look into native running of old software on Windows sometime. You can go pretty far back with the overwhelming majority of games, and most of those that are issues revolve around DOS (Windows 95/98) verse NT kernel (XP & foreward) and x86 commands that have been locked down for security reasons that some old games used. Despite the fact the games were obviously not "designed" with hardware from the Future in mind. You're overstating things that these days are usually handled by the hardware vendor's driver teams.
If you were a developer, would you rather have a firmware with a guaranteed-to-work-great set of built-in drivers, or an OS with drivers that may vary in quality for any number of different hardware configurations?
3) Proprietary systems are not immune to software issues, even in the relatively simple 8-bit era there were bugs in high profile titles.
but how exactly are those valid technological barriers made moot with so-called standard libraries?
Did I say anything about SDL? Are you refering to my mention of APIs, which are basically kernel interfaces? Or SDKs, which Console manufacturers need to know quite a bit about as they need to make them unless they're going to force game developers to have to go low level to make things work?
Each graphics card supports a different version of OpenGL
This is outright nonsense. The only time it's kind of valid is if you're going into proprietary system weirdness where for various reasons they've decided to deviate from the Khronos Group, which in turn only leads to a situation where development tools that take advantage of that have to be developed, etc. With relatively open systems pure Khronos Group OpenGL is used which is backwards compatible through the entire version line.
there's no guarantee what library Nintendo currently uses on their hardware (so a library port may be in order as well), and there's still the issue of drivers. [...] Also note that some applications running on that OS may interfere with the game, too. More variables means more testing, period. More testing is more man-hours spent _not_ developing the game. More time spent not making games hurts Nintendo's bottom line. Unlike MS and Sony, Nintendo is primarily a game developer. Making games for other systems would be self-sabotage and a very poor move; technically and fiscally.
I can't say I've seen a game developer that is particularly accommodating when their game code runs afoul a firewall or antivirus suite, which is rather rare to begin with.
? I take it you're unaware that through it's product history Nintendo has used fancy multiprocessor configurations involving heavily modified Intel 8080 derivatives [NES/Gameboy], a heavily modified 16-bit CMOS 6502 derivative [sNES] later modified to use a RISC 3D accelerator (SuperFX) and other plug in chips, a SGI custom solution Sega turned down involving a MIPS derivative [N64], PowerPC designs with ATI graphics [GameCube/Wii], and ARM [(ARM7)GBA, (ARM7+ARM9)DS, (ARM7+ARM9)DSi, (ARM11x2)3DS]. Note Nintendo and associated 3rd parties have something of a history porting older titles to newer hardware. Also note Nintendo has throughout its history released PC software, so it's not like they don't know how to do it there's just no business reason to do so with their frontline titles.
It seems that you use the Classic Sonic in the old 2D perspective and the new modern Sonic in the 3D Perspective well known from Sonic Adventure & Co.
