From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0052.html:

Annevk: "We'd like to retain this feature.
Although it has complexity, we've heard from both Firefox UI and
Firefox OS application developers that the moment your library gets
sophisticated, you want this for extensibility."

From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0109.html:

"I was asked to provide a use case for our stance. One that we've found
with Firefox OS is custom dialogs, quoting Wilson Page:

# I have an <x-dialog> component. It takes care of transitioning
# in and out of the viewport and appropriate styling contained
# elements (<h1>, <button>, <p>).
#
# I want to be able to extend this component to produce
# <x-dialog-alert>. In this case extending the prototype alone
# isn't enough, I need to also be able to extend the markup
# and styling of <x-dialog>.
#
# At the point of creation <x-dialog-alert> can add a second
# ShadowRoot that allows it to compose its own content
# inside that of the 'old' <x-dialog> ShadowRoot. Without this
# <x-dialog-alert> would have to duplicate all the markup, style
# and interaction code again."

From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0122.html:

"I don't think you need to duplicate anything. The super class can still
fill in the original shadow root, then the subclass can modify it. This is
the same concept of the prototype inheritance, your methods will shadow the
super class methods, but you can just call them and then extend the
behavior.

This is also the reason the created and attached callbacks are on the
prototype. So you can call super and use the parent behavior by shared
protocol."

From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0132.html:

"> This is an interesting approach that didn't occur to me! Similar to Anne's
> concerns, this would require you to have more knowledge of the internals of
> the super-class component. If you own both components then this is fine.
>

Yes, the main problem here is the degree of separation between creator and
consumer of the base component. The higher the degree, the less inclined
the creator will be to expose innards of the shadow tree to the consumer.

Multiple shadow roots solves the same problem as shadow trees (provides a
composition contract), but along the inheritance chain.

For example, multiple shadow roots make sense:

* if you are a maker of UI library that's strongly rooted in inheritance
and intend to for your base components to be used directly;

* if you are hoping to inherit from components with closed shadow trees."

FYI. I've written a memo about "Multiple Shadow Roots".

https://github.com/w3c/webcomponents/wiki/Multiple-Shadow-Roots-as-%22a-Shadow-Root-hosts-another-Shadow-Root%22

I'm not saying anything about whether we should remove multiple shadow roots or not there. Please consider it just for reference.

The resolution is "Remove for v1".

See https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting.

Let me try to update the spec. I might use this bug as a meta bug.

Moved to https://github.com/w3c/webcomponents/issues/90