That's actually the way webkit handles display: block (as in divs). If something needs that property, it means put it on a line by itself. All browsers do this by giving the element (let's call it element A) full width so that it spans the full width of the element it is relative to in order to knock its next sibling down below, which we've all probably noticed when hovering over an H1 or something in web inspector/firebug and saw that it spanned the whole window. However, if you specify a width for element A, browsers need to do something else. The solution webkit chose was give it the necessary margin on the right to accomplish the same thing, regardless of whether the user specifies a margin-right because it ''usually'' won't matter style-wise if it's display block and all proceeding elements go below.
There is an addendum. If the element is display: block; margin-right: 3px; AND float: left; the element MUST keep its margin. You will see that if you add float: left to your #inner in the test case above, you will get the correct outerWidth. This is not a jQuery bug, but a choice on how to implement display: block in webkit.
Regardless, a possible solution would be to float the element in any direction just long enough to get the correct margins, then put it back to what it was before. I went ahead and made a pull request that utilizes swap in getWH in css.js, and added a test in the dimensions component.