There's definitely something weird going on here.  Chrome appears to be doing the elision when there's no obvious reason to (width is 100% - so should be no overflow, right?).  Safari, Firefox and Edge don't elide at all, which I think is the correct behavior.

Oh sorry I understand the original summary now - indeed it's not just the elision but the element's width is not being updated when the text content changes.
Reproduced on Chrome 56.0.2924.58 on ChromeOS and Chrome 57.0.2973.0 on Windows

Suspecting objectIsRelayoutBoundary() in LayoutObject.cpp and that it returns true for the overflow:hidden object, so that we don't re-layout its parent when its child changes width. But I haven't verified this yet.

In the attached test, if you resize the window, the square appears.

Deleted: tc.html 361 bytes

tc.html 361 bytes View Download

Yep, that's it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da179e152dff0ab3e3dabc72299bd4fb586881c9

commit da179e152dff0ab3e3dabc72299bd4fb586881c9
Author: mstensho <mstensho@opera.com>
Date: Wed Jan 18 20:40:07 2017

Percent-width blocks cannot form a re-layout boundary.

A block with non-visible overflow can only form a re-layout boundary if both
width and height are fixed.

The block may be inside a shrink-to-fit container (there's no cheap and
reliable way to detect that), so that changes inside it may affect its width.

BUG= 681657 

Review-Url: https://codereview.chromium.org/2643703002
Cr-Commit-Position: refs/heads/master@{#444467}

[add] https://crrev.com/da179e152dff0ab3e3dabc72299bd4fb586881c9/third_party/WebKit/LayoutTests/fast/css-intrinsic-dimensions/resize-inside-percent-width-overflow-hidden.html
[modify] https://crrev.com/da179e152dff0ab3e3dabc72299bd4fb586881c9/third_party/WebKit/Source/core/layout/LayoutObject.cpp