FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan
proposal.
It reduces the implementation complexity: all of the selector-checking
logic in
http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria
is replaced with (what effectively is) a map lookup.
While some loss of flexibility is a cost, I think it's worth considering
this trade-off, especially if it is a sticking point for implementers who
are looking to reduce the overall cost of Shadow DOM implementation.
In fact, if we reach cross-vendor agreement and decide to go with the
slot-based approach, we probably should avoid adding extra sugar around
element names and attribute values as slot indicators, and instead double
down on developing a good imperative API that overcomes the loss of
flexibility.
:DG<