Well, Chrome is many things. One is that it's a browser, with a new security and performance
model based on separate processes for each page renderer and JavaScript interpreter. This is
beyond the scope of WebKit itself, so it won't make it up; Apple may decide to adopt some ideas
in Safari, but that's closed source and beyond the scope of the WebKit project.
Another thing new in Chrome is Google's Windows WebKit port. Apple already has a Windows
port, but it relies on their proprietary libraries that basically implement parts of the MacOS X APIs
on Windows. Presumably, Google is not using these, but instead has their own native Windows
webkit port (or has been contributing to the existing effort; I haven't been following that very
closely). This is good news, because if this is pushed upstream, it will mean that WebKit will be
freely embeddable on all major platforms (already available on MacOS X, GTK, and QT).
Another new piece is Google's JavaScript JIT compiler, V8. They claim that it's a lot faster than
previous JavaScript implementations, though both Mozilla and WebKit have made major
improvements in their JavaScript implementations recently, so we'll have to see how much
improvement it actually makes. If it is significantly faster than WebKit's
JavaScriptCore/SquirrelFish, as well as being reasonable code that is well written and
maintainable, then there's a chance it could be pushed up and replace JavaScriptCore, though
given the amount of work that has gone into JavaScriptCore recently, it's hard to say if people
would want to abandon it that quickly. At the very least, it should inspire other implementors to
work to make their implementations even faster, which is always a good thing.
There may be other bits and pieces that could be used upstream, like the integrated Google
Gears; it may need to get a little further through the standardization process before other
browsers want to seriously start implementing it.