The big question regarding the upcoming (and thoroughly unneeded) 2.0 version of this most dubious script is whether its authors are foolish enough to leave "Sizzle" (their QSA fallback) in the code. If they are foolish enough to offer a "solution" that breaks IE 8- users (or requires conditional comments to avoid doing so), can they possibly think that they need anything but QSA to query the DOM?
Another looming question is how a project that has no way to keep track of plug-in compatibility with just one fork going to handle two at once? Poorly I imagine, but that's for those who remain on board to worry about.
Let's deconstruct this "magic" script. It's roughly 70% "Sizzle" (and supporting functions), 10% "Live" (an atrocious event system), 10% outmoded special effects (which can be done far more efficiently with CSS3 transitions and animations) and 10% miscellaneous (and often wildly confused) DOM "normalization" functions (e.g. measuring the viewport dimensions, reading and writing attributes/properties, creating XHR objects, etc).
Throw out the query engine and special effects and we are left with the event system and a handful of confused DOM wrappers. See links at end for all of the information (and cross-browser code) you should need to completely extricate your project from jQuery before the coming "upgrade".
So if they cut out "Sizzle", there's really nothing left. As they are going for a smaller footprint (which won't help their performance much at all), seems only logical that they would axe it in 2.0. Of course, as a marketing effort, they are likely aware that they'll then have virtually nothing left to sell.
What possible excuse could they offer for leaving their query engine in 2.0 when all of their "supported" browsers have serviceable implementations of QSA? As with any disaster, you have to go back in time and follow the chain of decisions and events that led up to it. In this case, the first botched decision happened over four years ago:
http://ejohn.org/blog/thoughts-on-queryselectorall/
Three blind mice saw that the standardization of DOM queries didn't quite agree with their scripts and insisted that the specs were just "wrong". Of course, this was tilting at windmills; like it or not, they were now officially wrong. As they clearly planned to leverage the new standard when available, they would have to adjust their logic and reeducate their users.
I know what you're thinking: how could they make such a change without disrupting existing applications? Quite easily, by adding a configuration flag that switches between the old (wrong) way of querying (the default) and the newly standardized method, warning users that the old way is deprecated and will ultimately go away. Then they'd have been on the right road to eventually discard their query engine bloat. Regardless, this was over four years ago and both Dojo and jQuery have broken a lot of projects in the interim with dubious and divergent upgrade versions (often forced on developers due to compatibility problems with new browsers).
Unfortunately, their "solution" was mostly to do nothing; calling on QSA when available and falling back to their own incompatible code when not. This was, of course, crazy as it ensured that element-rooted queries would behave differently in even the handful of browsers they claimed to support. The obvious solution of changing their scripts to match what the specifications required somehow eluded them. Either that or this was a marketing decision designed to keep their users in the dark and dependent on their magical scripts.
Fast forward to the present. As predicted, jQuery has decided it no longer "cares" about IE 8- users and is dumping all of the code that made those browsers seem to work. Of course, IE 8 had limited QSA and IE 9 finally fleshed it out to (more or less) match the other major browsers in use today. But I predict they will reference the QSA "spec bug" decision from 2008 as an excuse to keep "Sizzle" in the mix. After all, if they drop it they have virtually nothing left to offer.
I suppose a project that has the gall to advertise itself as "CSS3 compliant" and "cross-browser" (it's neither) will have no problem misleading their users on this issue. If they don't, they will likely cease to exist as gullibility only goes so far.
Further reading:
Queries:
https://groups.google.com/group/comp.lang.javascript/browse_thread/thread/f80345226219d424
Adding and removing event listeners:
The load "problem":
Creating an XHR object:
Properties and attributes:
Measuring element dimensions:
Element positions:
Measuring the viewport:
This project is starting to put the pieces together:
https://github.com/rassie/jessie
If you want to learn and contribute to a worthwhile browser scripting project, get involved now. Only six months (or so) left until jQuery breaks in two. However it happens, the event will be a disaster for those invested in the project. Which version are we using? Which plug-ins will work with which version? How many visitors will be needlessly excluded due to jQuery's marketing machinations?
Why bother thinking about any of it? Just dump it as soon as possible and cut your losses. The same goes for Dojo and would also apply to Prototype if it hadn't died in the interim. It's not just that these projects feature execrable JS and browser scripting practices (e.g. browser sniffing); their authors are clearly focused on marketing, not logic. Their aim is to sell you support services, books, T-shirts, etc., not to help you succeed.