I'm not sure how useful this distinction is, as every job I've held had highly ambiguous requirements and a lot of trade-offs involved in building a working system from them. It kinda makes me wonder though - a colleague who'd been a PM at both Google and Microsoft said the difference was "Microsoft expects PMs to produce a spec that's thrown over the wall to engineers, who throw it back if there's any ambiguity. Google expects their engineers to have opinions about the product and to resolve most of the details themselves, only consulting the PM if there's something big where they need additional data." I wonder if Microsoft hires programmers and Google hires software engineers?
I don't think that's a fair assessment of the developers themselves. I would write it up to differences in product release mentality -- it takes a different mindset to put bits in a box vs a web server.
I'd kind of cheapens the craft when people look at it in this way, my AI lecturer last year was describing the different roles in creating an AI system and saying that that the job you want is a knowledge engineer is the position you want and the programmer is just a nobody who translates it all into code.
That's the distinction: We in the U.S. are (supposedly) going to retain management (and maybe design) while outsourcing the "lower level" work.
I originally continued with a longer comment, but it summarizes to: "Good luck with that."
My only option is to believe that "management/design stays onshore" is a way to keep current mid-level managers from pulling the ripcord right now, and at least getting all the programming and the technical managers offshore before everyone below director-level wises up.