The .selector property is internal, deprecated, and we hope to remove it one day. It does not represent the currently selected contents of a jQuery object.

My initial attempt at fixing this was by using the .selector property. I now understand that was a poor solution given that the selector function is deprecated. However, not accepting a jQuery object as an argument does appear inconsistent with other jQuery functions, and IMO this should be considered a valid bug.

There is no bug. You passed an object and it's available as the event.data parameter. It sounds like you're asking for a *feature* that would break compatibility with code that passed a jQuery object to an event handler, so we wouldn't implement that. http://jsfiddle.net/m2AA8/

Also, if you want to do what I think you are asking, just add an if to the top of your event handler, comparing the target to the list you passed in. It gets a little more complicated if you need to look up the tree (use .closest()) but not much. http://jsfiddle.net/m2AA8/1/

I think I described what I want to accomplish poorly. I want to use the .on() function to create a delegate in a similar fashion to how .live() used to work.

This works as expected: http://jsfiddle.net/tW3q7/1/

This does not: http://jsfiddle.net/TM3rh/1/

The only difference in the second one is that I passed a jQuery object instead of a string. I feel that you should be able to pass a jQuery object into this in place of the string and it should still work just the same. Or at the very least throw off an error of some kind. Right now, if you pass a jQuery object in instead of a selector in the form of a string, you get undesired behavior.

I feel like I'm repeating myself, but...

It's documented that the selector is a string, and that passing an object will put that object in event.data. I showed in http://jsfiddle.net/m2AA8/ that the current behavior can be useful, and no doubt there are people out there using it as documented.

What you're describing doesn't match the documentation, and what you describe as a bug can't be fixed without breaking the code of people who read the documentation over the past seven years and correctly used the API as documented. That seems unfair to them, doesn't it?

I'm not advocating breaking the existing feature (wouldn't want to victimize the people who RTFM). I simply want to enhance the behavior to keep the functionality consistent with what I've seen elsewhere in the library.

Granted - $.selector is deprecated so fixing this seems pretty daunting, as someone would have to fix whatever horrific bug is causing $.selector to be an unreliable way to tell what was matched and then reimplement it.