This seems more correct to me. Without the padding the content is clipped in older versions of Chrome and in Firefox.

+tab for spec cliarification.

Spec is clear - they go between the border and padding, not overlapping.

However, that's irrelevant here - note that the scrollbar is on the container, but the padding is on the child.  The scrollbar is definitely "between the border and padding" for the container, because there's zero padding there.

What matters here is how you calculate the intrinsic width of an inline-block with overflow:auto - it definitely starts as width of "Hello" + padding-right, but does it add in the scrollbar width as well?  If not, as Firefox is doing, the child is just *overflowing* (but overflow-x is set to "hidden", so you don't see a horizontal scrollbar) and sits underneath the scrollbar.  If there were two words, I think the line would end up breaking and move the second word down.

It turns out whether the scrollbar is included in the intrinsic width is undefined in CSS2.1, so... shrug? OUr new behavior is fine.

What is the rationale for changing the behaviour?

Is it important enough to cause regressions in existing sites that used to work consistently in all major browsers?

Is it important enough to introduce a case where authors need to take browser differences into account?

This fixed a number of issues where we incorrectly wrapped and broke layout which is less sever than adding the padidng in your case. It's all about trade-offs. If there are cases where this change broken content or functionality we'll of course reconsider.