First, the API calls would be the same.  So, the GPU wouldn't matter.

R500 does not implement proper DirectX 9 or 10, and I doubt any retail game used only API calls.

What Microsoft did with the orginal Xbox games is they essentially recompiled the games.  First they did that for the games that were common, so if they used the same engine.  Then next they did that for a few of the ones that featured less common engines.  They had MechAssault II but not MechAssault I, for example because the latter used a more common engine so they could make the changes necessary to the referenced library and any code changes and apply it to other games.

The same could be done to Xbox 360 games.  Recompile older Xbox 360 games and either update the Xbox LIVE components for Xbox One or leave them for the Xbox 360.

The architecture is too different for recompliation to work. The memory hierarchy is different, and retargeting a single 360 core at a single Jaguar core is too little power.

Is it really so hard to switch HDMI cords that this feature needs to be implemented?  Not to mention for this both consoles have to be on at the same time so your wasting energy.  Also lets say you do only have 1 HDMI port, if it is too big a deal for someone to switch cords then they can just use component on their 360 and have both connected.

No, a single core does not operate at the same cycles per minute, however a single core on the Xbox One's processor can do more work per cycle than one core of the Xbox 360's Xenon processor.  A single core of the Xbox 360's CPU does 38.3 GFLOPs.  A single core of the Xbox One's processor does 152.5 GFLOPs.  So, in the same amount of time, the Xbox One processor can do more than  3 times what the Xbox 360's CPU can do.

GFLOPs are not an accurate measurement of instruction throughput for game workloads. The Jaguar core is far less capable than implied by that number. It's definitely not 3x faster per core, and I would guess slower per core.

Programming on Windows means using Microsoft's C/C++ libraries if you're not coding in .NET.  You're not coding to the hardware directly. 

C++ is coding to the hardware directly in that it's sensitive to platform changes so that recompliation alone is not possible.

Also I seriously doubt 360 games only use Microsoft's APIs. For speed concious sections there will be direct memory management. Maybe even assembly code. Certainly speed tricks that rely on the exact hardware configuration.

You might get closer to it than .NET permits, but you're still using libraries provided by Microsoft.  Which means, as long as Microsoft updates the libraries to be code compatible with or update the code in the games to be compatible with the new libraries and recompiled with them, it'll work.

Retail 360 games don't just sit in the nice safe MS environment.

As far as memory goes, if you're addressing memory specifically (i.e. reserving blocks and moving data in and out of those blocks manually rather than letting the APIs do it, then you're still addressing a known block of memory.  As long as those blocks of memory line up with what is available, cool.  If they don't, then you have some work to do but still not a unfathomable task.  

Oversimplified. Incorrect.

The Xenox GPU was the basis for the R600.  As long as Microsoft's libraries were used, then those library files can be updated and the game can be recompiled.

No, it was an orphan project that had very little to do with R600 except that also had (a different kind) of unified shader. It's closer to RV520 in API terms.

Tesellation is a great example.  While supported on the Xbox 360, it wasn't fully implemented until DirectX 11.  An Xbox 360 game that used tesellation could be improved by utilizing the updated capabilities of both the newer GPU (AMD provides hardware support for tesellation) and API.

Tesselation is an AMAZING example of something that kills your argument altogether. The unit on R500 is completely nothing to do with the DX11 tesselation and uses instructions never found anywhere else.

Bottom line, it is extremely possible that Microsoft could do this.  The question is, would they do it for free? 

It would take as much work as a Wii -> 360 port. That is, a whole dev team's time for some months.