canvas.width/height effectively determine the window coordinate space as far as WebGL is concerned (eg. the size of the window within the page), so gl.viewport wouldn't break as long as people say gl.viewport(0, 0, canvas.width, canvas.height). If anybody's saying gl.viewport(0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight), that would indeed break. That's incorrect code; hopefully it's not common. I see two hits here, which perhaps we could get fixed: https://www.google.com/search?hl=en&q=
"gl.viewport(0%2C+0%2C+gl.drawingBufferWidth%2C+gl.drawingBufferHeight" Just two hits is promising, though.
I think the only major place it would normally cause breakage is with gl.readPixels, where you'll need to use the dimensions of the backing store. The failure mode would probably be things like screenshots only capturing the top-left quarter of the screen. There was a proposal to deal with this in 2d canvas, which could be used here too. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035112.html
readPixels would be changed to take CSS pixels (rather than device pixels, as it does now), scaling the output if it's not 1:1. A new method, eg. readPixelsHD, would be added, which behaves as readPixels does now, to allow reading full-resolution data for apps that are aware of it. This would avoid breaking current code that uses readPixels. (I don't think Ian has got to that thread yet, so it's unknown for now whether 2d canvas will go that route, but it seems like a good idea to me.)
There are other things that can go wrong, but I think they're mostly nonfatal. For example, if you create a framebuffer for an intermediate rendering pass using smaller Canvas dimensions, then your app doesn't explode; it just ends up rendered at the smaller resolution, which is a much more tolerable failure case.
That said, while the idea of canvas @width/@height determining the window coordinate space makes sense from an application developer's standpoint, I have no idea how that translates in detail inside the OpenGL ES spec.