Basically the intended use for this new API is the following.
You have your canvas as is, forget the world of retina displays, just think of CSS units, not physical pixels. Physical pixels have now been abstracted away.
You create your canvas in your document, you set your canvas to be 940px wide since your website is on a 940 pixel grid (for example).
You begin drawing to your canvas, and everything just works. You get high resolution lines, high resolution circles, shapes, etc. The canvas, while you interact with it in a lower resolution, is automagically upscaled internally for you, as if you where drawing vectors.
Where this becomes an issue is images. Essentially, you have to take the same route you took with the image tag or background images in CSS, except this is an entirely new context, for which to work in and the logic has now moved to the canvas generation specifically, as opposed to handling it in the browsers drawing layer (where it used to exist for Chrome, iOS, etc).
Images are automatically upscaled to fit. If you upscale your canvas you upscale your backing stores. BackingStore is the name given to the actual pixel data that the browser uses to eventually draw the canvas when necessary. Your BackingStore on a Retina Display Macbook Pro running Mountain Lion with Safari 6 is 2x the pixels of whatever you defined your canvas to be. If the canvas element is 100 x 100 pixels, the backingstore is now 200 x 200 pixels. Everything you draw to this 100 x 100 canvas is magically upscaled to 200 x 200 pixels. The problem is this is not a screen display issue, rather it's isolated to a very specific browser on very specific hardware.
The traditional methods of checking for window.devicePixelRatio will not help in this case, since it will occur as 2 in both Chrome and Safari 6, yet Chrome does not yet support this backingStore, although I bet it will soon, so simply sniffing Safari would be a lost cause.
What ImpactJS needs to do is actually create a new pixelRatio feature, that is independent from zoom since it serves a different purpose. The complication has become that the JS logic needs to determine this instead of the browser software. The JS engine now has to manage the real asset size vs the intended display size.
Based on my quick tests, this does not seem like a trivial change, but perhaps I am not yet familiar with the ImpactJS source to fully asses this. There could be a couple shortcuts I am not aware of.
My suggestion, is perhaps get rid of zoom/scale as such a high level argument, move it into more of a system option variable, and put pixelRatio up front and center as a new metric for controlling image quality.