Safari crashed on me while WebKit was open, and when I relaunched and recovered the session it showed me the sessions from WebKit and I have lost some important tabs because of that. The LastSession.plist file in Safari library folder is shared between WebKit and Safari which will cause confusion and loss of data... I would prefer to have the 2 session files separated ... adding a session manager is even better.
LastSession.plist is part of Safari, not WebKit. If you'd like to suggest enhancements as to how sessions are handled in Safari, please file an enhancement request at <http://bugreport.apple.com/>. This bug will be closed as INVALID to represent the fact that this is not a WebKit issue.
I would like to argue that the assessment of this entry might be incorrect. The way Safari handles LastSession.plist is perfectly fine. The problem is with WebKit (the nightly build application) using (and especially *writing to*) Safari's LastSession.plist. IMHO, the OP request is valid, and I suffered several times from the same issue.
The "nightly build application" is Safari, so that doesn't make any sense.
Since I didn't really understood your answer, I peeked into WebKit.app and Safari.app bundle. It turns out (among other things) that WebKit.app exec is 52kB (Safari.app exec is over 4 MB). So I downloaded the whole webkit source, and found theWebKitLauncher XCode project, which seems to be the one building WebKit.app Reading the source code there, I saw what I had been missing all along: WebKit.app actually launches Safari.app, after having connected it with its own WebKit framework. So that explains why this issue is not a WebKit issue. I wanted to document this here with this comment, for my sake when I have forgotten about that, sometimes in the future (and possibly for the sake of others with the same puzzle). Is there a way to work around this? Looking for the string "LastSession.plist", I found it only in Safari.app exec. So only a binary patch can redirect it ("LostSession.plist" seems mandated ;-)). I didn't try it. This may break Safari in spectacular ways.
There's not, which is precisely why I closed this bug.