Started playing this pack to get back into lemmings again - enjoying the pack so far

I ended up finishing 2-2 (Christmas climbing) with a spare builder so It doesn't feel like I hit the intended solution here and was probably overlooking something simpler (replay attached)

Remove or replace option "Don't Replay After Backwards Frameskip"
Apjjm is the only one using this option. Could you please tell us how important this setting is to you?
IIRC, möbius suggested this option, but complains that it doesn't work as he expects. So perhaps instead of completely removing this option, we can replace it by something that möbius and Apjjm like better?

Edit: On second thought i don't think i care too much for this option. I use click to cancel replays. I prefer not having to click to cancel after a single backwards frameskip though, as i only ever do that if i intend to edit the replay. If i could bind back 1 frame and cancel replay to the same key (never tried) i guess that would work.

I would like to submit my contest level & its harder variant (Crosstalk Conundrum) to the pack - even if ultimately one (or neither) end up getting used.

Edit: Replays attached

Replay of my solution to my own level.

Comments:

From what i can gather the reason the toolkit needs to delete levels (and i guess other resources) is that it makes copies of them. Perhaps the toolkit could just not take copies of the files, then it wouldn't need to delete anything? But before i describe my suggestion i would first like to describe my current usage of the toolkit.

Currently i version the pack i am working on using git. I have my folder structure for my pack set up similar to below:
Pack - Packs root directory
Pack/Dat - Contains all the stuff like rank signs & the .dat files used by flexitoolkit.
Pack/Dat/Levels - Contains all my levels
Pack/Replay - Contains replays for all levels
..And some other folders

As you can see, i store my levels in the dat/levels folder as i find it annoying to have to remember all the levels i updated since i last opened up the flexi-toolkit which i then need to go through and replace - because otherwise it would have outdated copies (I have already almost sent out versions of my pack with levels to test where i forgot to update something quite a few times). However, this means that the toolkit likes to delete any levels that are not included in the pack already. If it encounters an error during saving it can wind up deleting lots of levels! (Bug topic incoming on this)

Therefore i would like to propose the following system for storing level files:
Flexi-toolkit should not use a "levels" directory for storing levels at all. Instead it will store one .ini file per rank in this folder instead (maybe rename it to ranks). Levels being here will be entirely optional, maybe discouraged.
Each .ini file will list, in order of inclusion, a path to each .lvl file in that rank (The toolkit appears to somewhat support this already for hand edited .ini files - but it still makes a copy and resets the path on save).
There will then be a file called ranks.ini which will list the name of each rank, in order.

Example:
Pack/Levels/ - Folder where all the levels are stored in this example.
Pack/Dat/ranks.ini:
    easy
    hard

Pack/Dat/levels/easy.ini
    ../../Levels/just dig.lvl
    ../../Levels/we all fall down.lvl

Pack/Dat/levels/hard.ini
  ../../Levels/no added colors or lemmings.lvl
  ../../Levels/save me.lvl
If the toolkit encounters an error loading a .ini file (For example, it was deleted by the user, or moved), it can present an error about the missing file and continue on - it doesn't need to worry about leaving any copies behind, because at worst there will be an unused .ini file. The toolkit could either automatically clean up unused .ini files on save, or just list them in a separate tab with checkboxes and give the user a delete selected option. This  cleaning process shouldn't really need to be done often, as any dangling files can probably be treated as some kind of warning, if the user was exclusively using the tool these should not be present unless something already went wrong - in which case the best thing the tool can probably do is not make recovery harder by deleting things until the user is happy they have fixed the problem.

Ultimately it would be nice if all the settings in the toolkit were stored in a human readable way (I.e. do away with .dat files entirely) with path references to resources & that graphic sets / music / custom images etc could be stored using a file layout which is most amenable to the user's workflow rather than how the toolkit necessitates. Of course, this adds some responsibility to the user to structure their data in a reasonable way so that they don't end up breaking all the paths, but i would have thought people working on a pack does something like that already, if only to make it easier to make backups of anything they are working on.

Had a lot of fun playing the levels in this contest and making an entry - Congrats to flopsy for winning - Looking forward to whatever/whenever the next one is.

Solution for IchoTolot's "A Silent Scream"