With regards to the missing Shimmier (and Reacher) sprites: Yep, some people still haven't brushed up on their custom sprites, sadly. It's definitely true for Nessy's sprites (Highland, Shadow, and Machine), maybe also for Arty's (Underwater and Silhouette)? Christmas sprites don't have Shimmiers, either, because those require more work than merely recolouring standard lemmings.
Highland has shimmier graphics, but the relevant metadata in scheme.nxmi is missing. This should be a simple copy-paste from a scheme.nxmi that
does have them, so I'll sort this out later today - this will only require a redownload of the styles. I can probably even just make a small patch download that just overwrites the relevant scheme files, instead of requiring a full redownload of the 36MB styles ZIP.
The Xmas style has shimmier sprites, no worries there. As it's an official style, it falls on NL's developers (in this case, myself) to create the sprites for it where needed. If you're getting issues with the Xmas lemmings sprites, please double-check that you've downloaded the styles update.
Yes, Paint.NET can do this - there's an option on the fill tool to make it "global" rather than just "local", which will cause it to recolor every pixel in the graphic of the source color, instead of just the continguous ones. Make sure to turn antialiasing off when doing this. Although - as mentioned, I think this is just an issue with the scheme.nxmi files (it definitely is for Highland, haven't checked the other custom sets).
Every time you had to fix/alter a level it could be the case that an assignment in the old replay became impossible and was therefore discarded. So you fixed/altered your replay to the new version of the level, but the sleeper is still there and now the old failed skill assignments of the past come back to haunt you, leaving your replay database in shambles.
I fixed my replays for my packs for for the other packs I solved my replay database is now let's say unreliable.
I would propose: Failed skill assignments from replays are discarded again.
I think you've got the wrong idea here - and this is maybe my fault for not going into more detail about how this works / assuming you're familiar with the finer details of how queueing works overall.
As you probably know - the existing queueing feature is, if the user tries to make an invalid skill assignment, it'll be queued for a while (off-hand, I believe it's up to 1 second game time, but I could be wrong on this). If the assignment is successful, it's written to the replay
at the time the skill actually executes, not at the time it was queued. If not, nothing gets written to the replay.
The changes simply extend this to cases where the
replay tries to make an invalid assignment. The same behaviour regarding what's stored in any new replay, still applies. So, let's say you load a replay that tries to assign builders to Lemming 0, on frames 16 and 24; but on frame 16, the lemming is a faller. At frame 16, the assignment gets queued. Let's say, at frame 20, the lemming lands. At this point, he can be assigned a builder. Then, at frame 24, he's already building, so this assignment gets queued - but when the queueing expires, he's still building, so the assignment never happens. In turn, it gets removed from the in-memory replay data.
If you were to save a replay at this point, the newly-saved replay would contain just a single assignment - a builder at frame 20. As such, this will
not have unforeseen consequences on new replays derived from existing ones, as far as I can tell.
Any existing replays, of course, should always be double-checked when a level is modified, or a new update that could break them is released. In this case, I'm not aware of anything other than this change that might affect existing replays, although there's always the possibility of (a) a new glitch (which would mean NL, not your replays, need fixing); or (b) that Nepster made a change I'm not aware of.
Of course, if I'm misunderstanding what you were saying and the above isn't relevant, please correct me.