Finally, be sure to save it as a 32-bit PNG file - this is a good idea in general, as I'm not entirely sure how well NeoLemmix supports any other bit-depths.

This was very good advice. Just loading my 24-bit png.-files and saving them as 32-bit solved my problem completely, though there might have been more going on the background that I am unaware of.

I don't know if you've used the graphic set tool at all, but that has better support for things like what you're describing. When importing an image, you can either use the image's alpha channel for transparency, or you can manually pick a transparent color. Something like this should probably be added to the Flexi Toolkit, for sure.

No, I haven't used the graphic set tool at all.
But seeing that one of my graphics programs (PhotoFiltre) seems unable to save pngs in 32-bit, adding a little bit more support for 24-bit png-images seems useful. So yes, it would be nice to have something like the graphic set tool's options in the Flexi Toolkit as well.

Thanks for the further info on Fall Guy and the two solutions for Silent Circus. Unfortunately both fail in NeoLemmix, because the first builder turns around after the first brick. So it seems, that Silent Circus is indeed impossible under NeoLemmix mechanics.

Do you mean that these levels may work in old Lemmix, but you can't solve them in NeoLemmix? Or just that you don't have solutions for them at all?

Part so, part so. I have Lemmix solutions to Silent Circus and Fortress 13, but not to Fall Guy. In all three cases I neither know NeoLemmix solutions, nor have convincing arguments why such NeoLemmix solutions cannot exist.

Create a System.dat and save it. Then open it again, remove some of the levels and save the System.dat again. Built a .nxp now. Big surprise: The deleted levels are contained in the .nxp!

The reason seems to be, that the deleted levels (in the toolkit) got not get deleted in the levels subdirectory when saving the modified System.dat. Thus the toolkit finds them when building the .nxp and adds them.
When these level files are deleted manually, the .nxp contains once again the correct levels.

Question regarding rules 1 and 3: Do the restictions apply as well to preassigned skills? What about preassigning skills to zombies and ghosts?

Perhaps let us first ask how important trap recoloring really is:
1) Has anyone shown an interest in changing the lemmings sprites themselves?
2) If one replaces the usual lemmings e.g. with the christmas/holiday lemmings, just changing some colors in the traps will still look bad. It will get even worse when the custom sprites are even less similar to the usual lemmings. So all trap animations would have to be completely customizable. This sounds like a lot of work to code.
So I wonder whether this will (similarly as for gimmicks) only produce lots of code with barely anyone using it?

Unless someone convinces me that there is a lot of demand for custom lemming sprites, I would just say: Use the same trap/teleport animation for both lemmings and zombies - and regardless of custom images.

In my opinion the general guideline should be: The behavior should not depend on whether the lemming has fallen 5 pixels or 500 pixels. So the question should be: Do we want to trigger traps and teleporters for any falling lemming?

Conntinuous traps should always catch lemmings, even when they are falling.
For discrete traps I tend to allow catching lemmings as well, because traps like the spikes in the pillar style and the chameleon in the rock style should definitely catch falling lemmings. It would be extremely weird to be able to pass through them by assigning the floater skill only at the very bottom of the fall. The dragon in the medieval style would look completely weird when catching falling lemmings, but for sake of consistency, we shoud not have different types of discrete traps.
Regarding teleporters I have no strong opinion either way. But their animations suggest lemmings standing on the ground and actively entering the teleporter (similarly to hopping in the exit). Moreover as there is some transition time between entering and exiting the teleporter, it is not intuitively clear that the falling distance is preserved when teleporting. So I tend to using the same algorithm for both teleporters and exits.

Regarding the new Laser Deathroom 2: The idea is kind of nice, but it requires too much fiddling around/precise skill assignments/luck in the current setup.
The attached replay is made using C++ Lix.