TAStudio allows for more precise/easy jumping around, though it's not a huge bother if the script doesn't work with it because it's perfectly useful as it is
I looked into it. It might still be possible to support TAStudio despite its savestates not able to carry the script's data, but will probably require some hacks to make it work. The hack is that TAStudio movies have per-branch markers list, and it looks like you can associate any frame of a movie with a marker (which is just some arbitrary text). Normally markers are used by the user to annotate points of interest in the movie, but can certainly be repurposed by the script to store its tracking data in a per-branch fashion, given that some frames in the movie are almost never going to be annotated by user (eg. the first few frames after power on are not interesting and therefore prime candidates for script-inserted markers).
Essentially we use markers as a poor-man's method of allowing the script to "savestate" its tracking data to the branch. While you are messing around within the same branch, the marker will always be updated by the script after each frame to reflect the most current state of the branch: jumping backwards any # of frames => roll back all lag frames seen by script after the target frame you jumped backward to; advancing forward in time works as usual. If you switched branch in between frame updates, it restores the state (which would include the markers, ie. the script's own savestate) of the branch at the time you created it or last updated the branch, effectively working like you load a normal savestate. Saving the TAStudio project itself takes the current state (including markers) and save that, so reloading the project would restore to that state, similar to the branch switching case.
At least that's the theory. Having to cram the script's data into text and back on each frame could end up tricky performance-wise, will have to do some tests and see. This endeavor will definitely be more complex than adding support for normal savestates (which was already somewhat hacky and technically tricky in parts). Don't expect progress anytime soon.
===========
Fun 17 in 1270 Frames (~26s)
I'm wondering if there's a good reason to assign the floaters so last-second? You don't really need to optimize those lemmings--it's the last few to exit for save requirement that needs optimizing. In any case, just like in "We All Fall Down", I believe you should dig down exactly multiples-of-3 times before stopping the digger (it currently does 4). This will save 3 frames (ie. one physics update cycle aka "PUC") over non-multiples-of-3, assuming no changes in resulting lag frames.
Bashing the stairs next to the exit like you currently do, would turn a 4-pixel step into a 3-pixel step, which saves 3 frames (ie. one PUC) per change, though I don't know if the bashing itself may introduce lag frames that would slightly offset the advantage occasionally. With a digger+basher possibly lowering the 3-pixel step further into a 2-pixel step, you can save another 3 frames (1 PUC) each by not having the lemming do a jumper transition to go up the step, but again dependent on whether/how the additional skill usages may introduce lag frames.