Analogy with document fragment might be appropriate –

```js
jQuery( document.createDocumentFragment() ).text("test")[ 0 ].childNodes.length; // 1
jQuery( document.createDocumentFragment() ).html("<div></div>")[ 0 ].childNodes.length; // 0
jQuery( document.createDocumentFragment() ).append("<div></div>")[ 0 ].childNodes.length; // 1
jQuery( document.createDocumentFragment() ).append("<div></div>").html(); // undefined
jQuery( document.createDocumentFragment() ).append("<div>test</div>").text(); // test

// Same could be noticeable with other manipulation methods
```
Why those examples are inconsistent? Why tickets about them are not popping out all the time?
I think that's because of two reasons:
<ol>
<li>For every methods above, documentation states – it will work only in case when jQuery set consist</li>
<li>Very limited amount of people use those methods that way.</li>
</ol>

The same reasons could be applied for text node traversing, anyway, how jQuery set can became infested with text elements?
<ol>
<li><code>jQuery( document.createTextNode("text") );</code>,</li>
<li><code>jQuery( $.parseHTML("text")[ 0 ] );</code>,</li>
<li><code>jQuery("element").contents();</code>.</li>
</ol>

Targeting nearby elements through text nodes traversal seems as very rare instance, even in <a href="http://bugs.jquery.com/ticket/13265">13265</a> the problem is, as i understand a reporter, with undefined item that ended up in jQuery set, which this patch, if applied to 2.0, would fix. Additionaly, for some occasions, ignoring text nodes will produce the same result that would not be different from the current one or it could even fix some stuff, all these makes emerging of breakage less possible.

<blockquote> I don't think we've ever said we support document fragments in all APIs but this is letting them through.</blockquote>
If you do <code>jQuery("something").contents()</code>, which on my subjective opinion, is more conceivable use-case then others, you can get all the possible surroundings of those text nodes without using any of traversal methods, but just twisting the jQuery set, but if you have something like – <code>jQuery( jQuery.parseXML("xml") );</code> you can't get children of the document using jQuery methods, which might be essential for that type of code, same argument applicable to document fragment node.

More thoughts about why it should be done are <a href="http://bugs.jquery.com/ticket/13265#comment:6">here</a>, but this phrase –
<blockquote>This seems disastrous.</blockquote>
makes me nervious, i don't want to be the guy who breaks stuff, if we go with your solution – it would definitely will not break anything, if we go with mine – it would definitely will, affected amount of code can be relatively small comparing to all code that relies on jQuery but it can be big in absolute numbers, even if that code, in some sence, is strange and exceptional. So if you feel strongly about it, perhaps i should abandon my view and we should land <a href="https://github.com/jquery/jquery/pull/1146">this</a> patch instead.  

<blockquote>@dmethvin The middle ground is keeping code unchanged in both branches, but immediately getting very loud about the fact that text nodes etc. have never been documented as valid input and code relying on old (functional) behavior will likely fail when run on jQuery 2.0.</blockquote>
I don't think there could be a compromise, 1.9.x API should be the same as in 2.0, right?

<blockquote>I think that's a critical point, we're introducing a pretty big behavior change 1.9.0 to 1.9.1.</blockquote>
Hm, going slightly off-topic here: how point release for 1.9 would look like? If, say, <code>jQuery#andSelf</code> would be <a href="http://bugs.jquery.com/ticket/13283">removed</a> in 2.1, what number 1.9 will accrue when it would be removed from it?