The term 'projection' is often used as a synonym for the more correct term, coordinate reference system (CRS), which can include geographic and projected coordinate reference systems.
When a geographic CRS is displayed in two dimensions, its angular units are treated as if they are linear--they're just displayed. They are not displayed using a Mercator projection algorithm. The closest projection algorithm is Plate Carrée. Its forward equations are:
x (easting) = R*lambda (if the central meridian is zero)
y (northing) = R*phi
where
R = radius of the sphere (in your case the semimajor axis of WGS84 would be used)
lambda = longitude in radians
phi = latitude in radians
so you can see that true Plate Carrée coordinates are just scaled compared to displaying latitude-longitude values in degrees.
While the x equation is the same for the spherical Mercator equations, the y equation is different:
y = R ln tan (PI/4 + phi/2)
When you request data from an image-based web service like WMS, usually the layers have been cached (pre-built) in various CRS. The service then publishes which CRS are supported.
Note: Unfortunately, my company (Esri) is guilty of popularizing the usage of 'projection' instead of 'coordinate reference system'. I would just like to state that I started at Esri after that erroneous usage began.
I did the reprojection from a WGS84 hgt DEM once into EPSG:3857 and once EPSG:900913 using QGIS Lisboa.
While the first one is added to the canvas at the right place, the second is misplaced 21km North (as for you).
Rightclick -> Set CRS for layer reports EPSG:3395 is assigned to the 900913 layer with this proj string:
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs
This is definitely wrong, because +datum=WGS84 is an ellipsoid and not the sphere with a=b which was used when reprojecting the data.
QGIS 2.0 Dufour does not make it better:
+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
and that is the same gdalsrsinfo reports on the file reprojected by the same GDAL version to EPSG:900913.
Assigning EPSG:3857 to the layer moves it back in its correct place.
Just one more reason to avoid EPSG:900913 and use the offilical EPSG:3857. Here is some more background to the topic: http://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/
Best Answer
The coordinates Google maps show you are geographical coordinates. As you can see they use degrees as units. That's why the value is between -180 and 180. Google uses WGS 84 to calculate distances and show coordinates on the map. But the map itself is projected with the Web Mercator system (3857), but that is not the EPSG of Google Maps when it comes down to coordinates and distances.
The issue why they are using two different systems is because of some general problems: WGS 84 is nice for calculating distances worldwide. But they are in degrees and not meters or feet. Also it is not well suited to show a map of a 3-D earth on a 2-D map. Therefore you need a projection (https://en.wikipedia.org/wiki/Map_projection).
The problem with the Web Mercator is that it can't be used for calculating distances as they differ quite a lot from the real distances. Usually a map projection is only suitable for a smaller distinct area on the earth. That's why you have for example UTM zones(https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system). But the Web Mercator tries to show the whole earth in a single projection. But that is only a compromise for presentation.