Here's the test code on jQuery edge: http://jsfiddle.net/AkKsv/4/

This is the intended behaviour.

Description: Creates a new copy of jQuery whose properties and methods can be modified without affecting the original jQuery object.

http://api.jquery.com/jquery.sub/

The bug that Matthias is reporting is that the selector doesn't even work on the sub.

The reason is because jQuery.expr (née Sizzle.selectors) is cached in a closure variable named Expr and that is what is used by both jQuery and $sub. As incredibly dumb as it seems, that is actually the intended behavior of jQuery.sub -- the "sub" uses all the closure variables of its source.

Our intent for 1.8 is to deprecate jQuery.sub for removal to a plugin in 1.9, so I am inclined to close this wontfix and frantically wave everyone away from using it.

I stumbled across this bug when trying to modularize our JS using RequireJS. To keep plugins 'private' to modules where they're required i've been using sub and as the UI Widget Factory creates a pseudoselector out of the box i couldn't use it even it's there when looking at $sub.expr[':'].

As a cross-reference: https://forum.jquery.com/topic/keeping-plugins-to-yourself-with-requirejs

I'm closing this wontfix for the reasons given above. It's really inherent in the design of jQuery.sub.

@dmethvin, should I bring newInstance back from the deads so that we can finally have a proper way to create a new instance of the lib (including attach the new instance to a new window)?

@jaubourg, you should run newInstance by gibson042, he's got a soft spot for jQuery.sub and would like to keep it. So maybe he'll be interested in an alternative. But I still think any solution should be battle-tested as a plugin before we talk about including it.