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<