I think the only difference is the User-Agent: header in the request.
Here are the User-Agent headers sent by Chrome on my Android device:
Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76K) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.45 Safari/535.19
Notice the word "Mobile' in the first one, and also the mention of Android system and device. Checking these, I see that it also provides false information - namely X11 and x86_64 - to closely match the value sent by the Desktop Linux version of Chrome.
One other slight difference is that the request appears to have been to the last intentionally entered URL before any re-directors moved it. For example:
Given: somesite.com sniffs the agent, sees Android, and does a document.location += "/m";
Then: the browser will have a URL of somesite.com/m
But: if you "Request desktop site" it will change the User-Agent and re-request from somesite.com
Unless: you had gone directly in on the mobile URL of somesite.com/m in the first place, in which case it just reloads somesite.com/m.
I would expect that this works with HTTP 301 and 302 redirects, I know it works with document.location changes (at least as described), and would speculate that it works with <meta> refreshes.
Just wanted to point out that Chrome now not only changes the User-Agent but also ignores the original viewport meta tag if you "Request Desktop Site". Thus it won't be necessary to sniff the User-Agent anymore and you can rely on the viewport change as most responsive sites will automatically do. See this Change for further reference.