Are you sure it is that simple?
This page is food for thought: http://ejohn.org/blog/sub-pixel-problems-in-css
There is no single definition of pixel: http://en.wikipedia.org/wiki/Pixel
My view is that css should never have divided into screen and print but should have defined an infinitely scalable standard like postscript.
Life was simple in the days of my Mac Plus - 1 pixel was the same as 1 point and both were 72 per inch - all screen text was rendered as 1 point dots and many printers did the same thing. As an Electrical Engineer I knew how this corresponded to the electronics. You would think that with separate addressable elements on modern flat screens life would be even simpler - alas no. In the meantime MS confused the situation with scalable screens and their 96 dpi.
I would prefer all calculations to be reasonably high precision with any rounding done at the last moment and preferable by the output device. This would minimise rounding errors and reduce the need for separate print css. I arrived here after hand coding postscript and marveling at its scalable elegance. Before the days of email I used to customise Word 5.1 memos with a quarter pixel line a quarter inch in from the edge. It had 45 degree corners. The next year I used double lines a few pixels apart. These printed well on 300 dpi laser printers.
The sad fact is that the fault lies with CSS standards which give little guidance about resolution and hence browsers do as they please.
Another quirk - early browser scaling functions always scaled points and never pixels - not only did this preserve image sizes but it was easy to protect critical css items from scaling - whilst the modern 'Zoom text only' protects images there is no longer any css control.
In relation to the original post here. I have noticed that all my browsers stop reducing character spacing at the point where the characters touch - ie the characters do not compress or overlap. This depends upon what the characters are and which font is used.