Is it accurate to assume the positionings of the two entrances are calibrated precisely, so that they effectively match exactly where the lemmings would be located had they been fallen and landed from the original entrance under ABCB ordering?

Based on my limited past participation, although every new skill had been used in at least one solution I've posted, I believe the swimmer had been least used so far.  So I'd guess that for the levels containing both water and traps, leaving swimmers out of the skillset in the supplied reference levels would be least likely to require player to change the skillset themselves.

Did the cloner already exist back in namida's original formulation of challenge?  The cloner is the only reason why number of lemmings lost can deviate with number of lemmings saved in the reported solutions, AFAIK.  We are still taking the originals' number of lemmings to save as binding AFAIK, just that you can lose more than you can originally by compensating the losses with use of cloners.

I don't really interpret the original level's save requirement as a requirement on number of lemmings lost, though I can see how someone else may subscribe to that interpretation.  But the thing is, you can't define "number of lemmings lost" as a solution criteria in NeoLemmix today--the determination of whether you pass a level or not is still solely based on number of lemmings saved.  And it's always my interpretation that this challenge is to imagine changing only the skillset and nothing else about the level, and then ask whether the resulting level can be solved in NeoLemmix.  That's it.  In which case the save requirement should remain a save requirement and not a loss requirement.

I'm not completely opposed to DOS save requirements but I do feel the Amiga ones are preferred.  As far as I remember, only a few levels in DOS deviated from Amiga, and in all cases the DOS deviations "water down" the levels' difficulty.  Many other ports follow the Amiga statistics as well if/when they feature the same levels, whereas I'm not sure whether the DOS deviations were ever seen in any other ports.  And like Proxima said, if we already adopted Amiga's having 100 vs DOS's 80 lemmings for most levels, and adopted all the water in Amiga that were taken out on DOS, etc., we might as well be consistent all the way and choose the Amiga version for everything else about the level.

As for the new skillset, I think to fit the spirit of what we are going for, we'll need to give the player free reign in choosing which of the new skills to use.  It could mean the player having to modify the level from time to time to incorporate the skillset he/she wound up using.

I don't see a problem with #3 in terms of implementing it, however the issue is - what happens if the assignment being deleted is already one that would fail, but has somehow remained in the replay, with further actions at a later point (that would be interfered with by the above algorithm)?

Isn't that exactly the same as my #4?  A failed cloner assignment is one that would've created clone -N but didn't.  All future assignments in the replay to ID -N will also fail because there's no -N.  You can elect to delete -N now, removing all assignments involving ID -N from the replay, then adjust the IDs of -(N+1) onwards.  Or you can leave it in the replay as a defunct record.   If you do leave it, you must still subtract one anyway for the next clone ID to use.

Basically there's a fixed relation between the ID to use for a newly created clone and how many cloner assignments (both successful and defunct) have been executed so far.  This saves you from having to explicitly record the clone IDs into the records of the cloner assignments, at a cost of having to maintain this relationship correctly during any insertion/deletion of moves.

This is why I think a better approach is to attempt to uniquely generate an ID number for cloners.

That's fair.  If you change the format so that for cloner assignments, you also store the new clone's ID in the replay record for the assignment, then all you have to do is to keep decrementing (ie. more negative) to get the next cloner ID to use, and it'd be unique.  In other words:

- When you load a replay, scan through the cloner assignments (which would now contain the IDs used for the newly created clones) to find the lowest (ie. most negative) clone ID used.  Subtract 1 from it to get the number (N) to use for the next cloner assignment.  Note that this means N = -1 for the case where there's no replay or no cloner assignments in the replay.
- If the assignment comes from a replay, then ignore N and just use the stored clone ID for the new clone being created.
- For an assignment not coming from a replay (ie. from an actual player-executed assignment, or an inserted assignment during editing), use N for the clone ID and subtract 1 to update N afterwards.

In this system, you don't have to ever readjust any existing clone IDs in response to insertion or deletion of cloner assignments, since there's no longer a relationship to maintain between number of clones made so far and the IDs of the clones.  You can still propagate deletes (if you want to) to delete all future moves on the deleted clone plus all of its descendant clones, since the cloner ID of the clone created is part of the replay record for a cloner assignment.  Assignments that become invalid has no impact since any assignments from the replay don't change N, you just use the stored ID.

Off top of my head, I don't believe there's any simple system to assign unique clone IDs if you can't also store those IDs as part of the replay records of the cloner assignments.
 

Backwards compatibility on the replays would likely need to remain indefinitely; either this, or a "replay update" feature would need to be built into NL itself. While backwards compatibility is not a particularly difficult task, updating a replay without outright playing it back would be almost impossible (again, due to the possibility that some assignments in it are already invalid).

Yeah, unfortunately I don't see a way around this.  The old format is based on indices, and failed cloner assignments will definitely affect indices in the same way a delete of a successful cloner assignment during replay editing can.  And there's no way to predict whether the assignment is ok or not without outright playing it all back.  This is always a problem regardless of what system you choose for the IDs of the clones.

With the proposed ID system, to complete the fix, whenever you delete or insert a cloner assignment, you:

1) See how many cloner assignments occur (and thus how many cloners created) before the affected cloner assignment.  The IDs of those cloners remain unaffected by the edit.
2) The IDs of the other (later) cloners in the replay will need to be updated to account for the deletion or insertion.
3) In addition, in the case of delete, all future moves of the affected cloner (as identified by ID) will need to be removed from replay.  Note that some of those such removed moves may themselves be cloner assignments, so you'd need to reapply 1-3 as well.

For the UI, it may be worth considering a confirmation popup whenever user deletes a cloner assignment, as it can potentially remove a whole cascade of later moves stemming from the clone that no longer exists, plus all further clones descended (once or more) from the deleted clone.

4) Any edits (not just to cloner assignments) may potentially result in a cloner assignment in the future failing, specifically if it causes the death of the source lemming you are cloning from.  You can react to this case one of two ways:
  A) When it occurs (ie. the replay just played the move that no longer works), treat it as a delete of the now defunct assignment and apply all of the above; or
  B) When it occurs, you still move on to the next cloner ID even though the cloner assignment didn't actually clone anyone, and you leave the defunct cloner assignment in the replay.

#4 actually can occur even without cloners involved, an edit might cause death of a lemming rendering a later assignment to that lemming no longer applicable.  I don't know if NeoLemmix today tries to clean up such defunct moves as they occur vs leave them in the replay.  There may be an argument for keeping them, as user may want to tweak the edits that broke these later assignments so that they are no longer broken.

I think the above is complete, but feel free to poke holes at it.  It is somewhat complex but doable.  #3 is particularly tricky to get right and maybe I'll provide a pseudocode implementation later.

I seem to remember the lemmings move a little bit faster on NES compared to traditional versions like Amiga and DOS, although it's maybe also possible the in-game timer also moves correspondingly faster as well, I don't remember about that part.  Either way, I hope the NES recreations, if keeping time limits, take into consideration that aspect and have actually tested the levels accordingly, so that generous time limits remain generous and tight ones still achievable, on the recreations in NeoLemmix.

Whether that's a backroute or not is somewhat debatable.  Unless the mechanics changed in NeoLemmix, the builder that seals up the one-pixel corridor will not himself be able to turn around, he will still follow the way up and eventually splat unless you do the splatform anyway.  The only reason you don't need to bother is because the level lets you lose 1.  At the same time, lose 1 is rather unlikely if you did do the splatform approach, unless you're slightly careless at the beginning when you need to spam-build a little.

It's also surprising how much building you need to make the splatform safe, you pretty much almost have to start building as soon as the lemming finishes falling down the cliff, or your splatform apparently won't be quite high enough to stop the splatting.

Honestly I don't find that level terribly interesting, but if people actually want to include that level in Redux and yet you're really bothered by the seal-the-corridor route, you could consider changing save requirement to 100% so that the splatform must be done.