Actually a <select> element will get not only the direct children <option> but also get non direct children.

For example, 

​<select>
<option>foo</option>
<p><option>bar</option></p>
</select>​​​​​​​​​​​​​​​​​​​​​​​​​​

both 'foo' and 'bar' will be used in this case.

It seems this description is not accurate enough. I'm not sure we have enough descriptive power to explain this behavior using Shadow DOM.

(In reply to comment #1)
> Actually a <select> element will get not only the direct children <option> but
> also get non direct children.
> 
> For example, 
> 
> ​<select>
> <option>foo</option>
> <p><option>bar</option></p>
> </select>​​​​​​​​​​​​​​​​​​​​​​​​​​
> 
> both 'foo' and 'bar' will be used in this case.

Right, but in this case, the HTML parser is playing tricks on you. Look at the resulting DOM tree: you'll see that <p> is silently dropped. However, if still you try to create this structure imperatively, you'll see that only <options> that are direct children are shown:

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cselect%3E%0A%3Coption%3Efoo%3C%2Foption%3E%0A%3Cp%3E%3Coption%3Ebar%3C%2Foption%3E%3C%2Fp%3E%0A%3C%2Fselect%3E%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%E2%80%8B%0A%3Cscript%3E%0A%0Avar%20option%20%3D%20document.createElement('option')%3B%0Aoption.textContent%20%3D%20'baz'%3B%0Avar%20p%20%3D%20document.createElement('p')%3B%0Ap.appendChild(option)%3B%0Adocument.querySelector('select').appendChild(p)%3B%0A%0A%3C%2Fscript%3E

I think <select> should not have an insertion point. The spec should be amended to treat it along with input, etc.

The spec should ensure that:

<select>
    {SR}
        <option>Asparagus
        <content>
    <option>Banana
    <option>Pear

should render "Asparagus", and not a select box (and definitely not a select box with Asparagus, Banana, Pear.) The reason being that the selectedIndex of Asparagus does not make sense. Asparagus is not in the data model of the select element.

(In reply to comment #3)
> I think <select> should not have an insertion point. The spec should be amended
> to treat it along with input, etc.
> 
> The spec should ensure that:
> 
> <select>
>     {SR}
>         <option>Asparagus
>         <content>
>     <option>Banana
>     <option>Pear
> 
> should render "Asparagus", and not a select box (and definitely not a select
> box with Asparagus, Banana, Pear.) The reason being that the selectedIndex of
> Asparagus does not make sense. Asparagus is not in the data model of the select
> element.

It can't render "Asparagus", since options are not rendered.

Can you explain the problem you're seeing with <select> having an insertion point?

We should not add any special cases to Shadom DOM at this point. 
Once the spec is otherwise stable, there could a yet another
spec defining additions to HTML elements (if really needed).

(In reply to comment #4)
> It can't render "Asparagus", since options are not rendered.

That is OK.
 
> Can you explain the problem you're seeing with <select> having an insertion
> point?

On reflection I think my beef is not with whether it has an insertion point, it is the relationship between option elements in the flattened tree and the HTMLSelectElement’s data model (selectedIndex, etc.)

(In reply to comment #6)
> (In reply to comment #4)
> On reflection I think my beef is not with whether it has an insertion point, it
> is the relationship between option elements in the flattened tree and the
> HTMLSelectElement’s data model (selectedIndex, etc.)

Ah. the data model shouldn't need to worry about the flattened tree. It only looks at the children of <select>. Having an insertion point inside of a <select> doesn't seem to influence that in any way.

(In reply to comment #5)
> We should not add any special cases to Shadom DOM at this point. 
> Once the spec is otherwise stable, there could a yet another
> spec defining additions to HTML elements (if really needed).

Yup. That type of spec would be an awesome improvement for http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#bindings