Let's rule out any distinguishing between "saveable" and "unsaveable" lemmings, except for the special case of zombies. This one is simple because zombies are never saveable - they cannot exit and cannot be transformed to a state where they can. Anything else, such as a blocker, needs further checks to confirm if it really is unsaveable or not. Even a neutral blocker requires "do only neutral blockers, who are not overlapping teleporters, remain?" Whereas "do only zombies remain?" is already tracked, and will always be tracked as part of calculating the remaining alive lemming count.

Let's also be clear that, I'm not going to implement every option that simply "might" be liked. If there is no or little interest in a particular behavior in practice, it doesn't need to be added, especially if it only saves a single button press. Poll results show no interest at all in the exit behavior; not much for pause either but not outright nothing.

Distinguishing between "player has nuked" and "player has not nuked" is worthwhile to consider as a special case. There is always the option to add a delay of a few seconds after the last lemming dies, to handle rewinding in nuke solutions.

Here's an example of what I was talking about earlier with bashers. Feel free to count it as an entry if you like (though there's almost certianly room to fine tune it to take even closer to the full 8:20 without making execution too difficult - I'm only really trying to illustrate the concept here, of how a level can be time consuming but not remotely interesting).

I'd think you'd get more value, especially considering the general philosophy of NeoLemmix, if you were to base it on how long it takes you (from the start of your first attempt) to find a solution. Your call, of course, as it's your contest - that's just my general thoughts.

Fixed in commit 51fa561.

Okay, so it doesn't seem to outright cache them; it just doesn't regenerate it if the previously-rendered preview was for a level with the same ID as the current one. It should be easy enough to change this to use another factor (I believe performance reasons is why this happens at all; so not going to remove the check altogether).

Ah, I see the issue upon looking closer - in the grouped pieces, some pixels are becoming non-solid where they shouldn't. I'd have to look into the code to figure out why, but this is definitely a bug. I do notice it happens specifically where the two pieces overlap - which should not become non-solid when the non-overlapping pixels remain solid (as they would be more opaque, not less).

Regarding the steel - when steel is involved in overlapping semi-transparent pieces, it depends how semi-transparent they are as to what the result is. As a general rule of thumb, if a given pixel is opaque enough to be solid when placed not overlapping other terrain, it's also opaque enough to overwrite steel with non-steel physics.

The editor does not handle semitransparent terrain properly. This is a known issue but hard to resolve with how the editor is written.

That's an excellent point. I should flag such cases in mass checks even if the replay ultimately still passes.