Perhaps it's worth expanding on this a little. We are already seeing a few rival systems appearing who will offer just that. Ouya will offer a box where your games get better over time, to some degree, as you upgrade the hardware. SteamBox will provide the same. If Apple create a set-top box, that'll provide the same. And MS already have a forwards compatible platform that allows your old library to be played in better and better quality in Windows. That could be a significant advantage next-gen against a rival who's library is a one-stop deal. If MS communicate effectively that it's Xbox Forever, than my options will be: PS4 that may be notably better than XB3, but who's library will be outdated and a dead-end in 4ish years; or XB3 and a family of improving boxes I can buy into when I feel its time for an upgrade, including PC even, taking all my library with me. That's a compelling argument.
There's a whole other two or three threads discussing this (Upgradeable console etc.) for those who want to argue for or against, but the key point is this is clearly a valid business strategy for MS and so shouldn't be looked on with surprise or consternation. We might well see a disparity between Orbis and Durango that goes beyond hardware differences, but that may also result in Durango (DirectX, Windows) being the preferred platform for gaming in the coming years.
Interesting stuff, this.
I wonder though, how feasable this is from a software point of view?
Take an example: Microsoft launched with Project Gotham Racing 2013 this fall on Xbox2013. Then, 2 years down the road, Microsoft bringts out Xbox2015 and by then, Blizzard (or whoever develops PGR) bringts out PGR2015 with it. Now, the interesting thing would be that both games both run on both Xbox versions - hence the thick API.
Is this really possible?
I know, this is more or less doable on PC gaming if you look at it. Though at the same time, the PC gamer audience is very different. With the million of different hardware, people there expect a bit of fiddling, framerate hickups, bugs to get things to work properly. Those are some of the reasons to why many PC gamers converted to a fixed hardware platform for gaming back in the day...
If Microsoft (or anyone) can pull this off - the games and hardware that are forward compatible would need to run well and most importantly remain playable. I would expect framerate to remain constant, meaning that in my hypothetical example, PGR2015 would need to run as well as PGR2013 on the Xbox2013 - but both would run (especially PGR2015) with nicer graphics on Xbox2015.
Now, I guess if newer games are limited to graphical upgrades, this is probably quite easy to achieve.... but my thoughts are, if the next iteration of hardware is that much better than the old one it's technically replacing, how do you deal with games pushing the envelope (well pushing the API) with better AI, physics, better gameplay mechanics?
If you want to remain compatible with the first SKU you've launched with, you are also limiting developers to the possibilities that the 2013 hardware offered - meaning, probably less innovation on that front. So 2015 hardware might not be all that attractive afterall, with the exception for better graphics. I don't think it's possible to design a game with better 2015 hardware in mind (think of bigger worlds or gameplay mechanics that aren't possible on 2013 hardware) and then simple turn off features to make it run on 2013 hardware without completely changing the gaming experience or altering the game itself. Well, maybe you could, but then you would be designing the game with those limitations of the weaker 2013 hardware in mind. I'm not sure a API can do that for you, which IMO sounds like a lot of headaches.
And if you simply ship games at some point that don't run on 2013 hardware... well... then you're not forwards compatible anymore.... which, to some degree defeats the thick API in the first place. Well, I guess you could say, new games are at least compatible with 4 year old hardware before you phase it out which would smooth things considerably... Would it work?
Dealing with this kind of problems from a software centric point of view... This would make one interesting topic, that's for sure.