API-wise, the proposal is to add a QWebFrame::scriptEngine() function that returns a QScriptEngine. That would enable usage of the full QtScript API to manipulate the frame's JS environment.
On the other hand, WebCore doesn't use the JSC C API, which means it's sensitive (and must be adapted) to changes in JSC in WebKit trunk. This means that QtWebKit still needs to use the JSC from trunk, not from QtScript's external copy.
Hence, the only way this can work in practice is that the upstreamed QtScript is built as part of building QtWebKit, and QtWebKit links against that version of QtScript rather than the one that ships with Qt.
For the V8 scenario, we have the situation that V8 doesn't live in WebKit trunk. The V8-based parts of WebKit use the public V8 API, which is stable, but there will probably still need to be some V8 version constraints (keeping up-to-date with the version used by Chromium?). One possibility is that Qt contains a copy of V8 that also QtWebKit can use (V8 headers installed along with normal Qt headers). V8, unlike JSC, can easily be built as a shared library, so there shouldn't be any issues with symbol visibility and whatnot.