To clarify, this would let people style the <shadow> element, however it would only affect inherited values since <shadow> element is not itself rendered?

The news widget use case in the spec would get more utility by @host identifying <shadow>, since it is still a news widget. But what is the essential issue? Is uniform composition like that always the case? Maybe more use cases will be illustrative.

Bug 18382 has a different approach to the problem.

When shadow DOM is used to create controls/widget, the @host rules could be seen as a way to provide default styling for the box, surrounding the said widget. 

For example, imagine that <input type="text">'s typical outline is actually styled using @host rules. 

Now, I want to add small icon inside of the input field to indicate something about the text content (calendar icon, for instance, to click and bring up a date picker). Always applying @host to the shadow host is the desired behavior here, since when I include the older shadow in my calendar icon shadow DOM subtree, I still want the text field's outline to be on the host, not at inclusion point.

However, if instead I want to add, say a password-strength indicator to the right of the field, I do want to put the outline styles somewhere on the <shadow> (but where?)

Punting until next draft.

There's no @host anymore, closing.