Oh, I'm perfectly aware of the limitations, but don't tell me that Microsoft couldn't do it if they wanted to - they most certainly have an in-house native SDK for the WP7.x so all they'd have to do is just add different targets in VS and of course limit API usage and such for each platform specifically, but you'd still be able to use vast of the business logic from your app to target both platforms.

It would be a pointless thing to do from Microsoft's perspective, but would gain them some positive PR. They judged that their existing small user base is not worth all the trouble and I'm okay with that, I just have a problem with rationalizing why something can't be done. WP7 to support native 3rd party would be a breeze, to have a layer of WP8-like APIs on top of it would be a bit more difficult, but still - it's not as if Microsoft couldn't do it, nor that the hardware is the biggest limit. FFS, I did native coding for a device with 32MB of RAM and something that cannot be called a CPU by any modern definition of the word, running Windows CE - don't tell me I couldn't do that on the WP7.x if allowed.

The thing is, Microsoft had three viable paths in this transition:

1) Build a MinWin kernel for the existing devices
2) Back-port all non-HW restricted goodies to WP7.x devices (and that includes native SDKs with similar APIs and so on)
3) Just say - eff them, give them some of the Start screen bling and call it a day

And they've chosen the third one. I'd even argue they did the right thing here, at least from the financial and development time point of view, but don't give me that crap that Microsoft couldn't do it any differently.