A few more thoughts on the Magic Pink issue:

First: it sounded from the initial bug reports that the workaround to bulk remove Magic Pink from the files worked. Might this be worth doing out of the box, and then culling Magic Pink support from Lix? Common image formats and editors have supported transparency for a long time; does Magic Pink still make sense in 2023? Does it save storage space compared to transparency after compression? It can't be saving CPU time since we have to replace it with transparency at runtime. And while it's not a very common color to actually want to use, it does mean that sets can't make use of it because it will always be changed to transparent. It's also a value that people have to memorize (even if it's not that hard) in applications where Magic Pink is required although my understanding is that Lix supports actually using transparency just fine so that's not as much of a problem as it could be.

Second: it seems likely that other recoloring is affected too, although it wasn't noted in the original report (while you noted that some UI elements wouldn't be recolored, we don't have any confirmation that this is the case). Knowing exactly how other recoloring is affected could be useful. If it's a +/-0 issue, for instance, I suspect recoloring would likely function properly when we're replacing a color that contains no 0 components. If it's something else (perhaps padding, perhaps some other issue we haven't thought of), then it's more likely to break consistently. But we can't know for sure without being able to test.

One advantage of Spawn Interval is that the direct correlation of the values to the result makes quick estimation of the amount to change it easy. If I want to double the release rate, that's halving the time between spawns, thus I want to cut the spawn interval in half. When you think about it that way, you can take a lot of the trial and error out of reaching the number you're looking for. And if you really want to do frame perfect SI/RR twiddling... well, it's not exactly hard to do that with RR either, as you can just figure out, "Yep, that's one frame off, gotta go up/down one... two frames off, so adjust by two..." because of the way modern NL RRs map to spawn intervals (and in the traditional scale, it just becomes an adjustment of 2, 4, 6... instead of 1, 2, 3...). So blocking spawn interval doesn't actually discourage these frame perfect RR/SI shenanigans at all and in fact makes quick estimations (the kind of RR/SI adjustments you might actually want to encourage) harder:

What is double RR 50? I don't know. It might be 75. I think? Could be wrong. IIRC the formula for NL SI to RR is 103 - SI = RR, and thus SI = 103 - RR so 103 - 50 = 53. 52 / 2 = 26 SI. 103 - 26 SI = 77 RR. So we got close, but... not quite (in practice it should be close enough in most cases). It looks like there's a bit of a pattern there, although I haven't proven it holds true for arbitrary values, where we want to increase the RR by half the remaining distance to 99 to double the release rate, but that's a bit harder to mentally calculate than simply dividing a number by 2. Quick, make spawns twice as fast with SI 28: that's 14, easy. Make spawns twice as fast with RR 75!... uh... that's gonna be, like 80 something I think? (it's 89) (these calculations assume the current NL scale, though I suspect they'd still work for the traditional scale, albeit with the SI equivalents being different, but I didn't actually check for the traditional scale).

And, of course, as mentioned, the NL RR scale almost completely different from the original game RR scale, matching only at RR 99.

Since SL doesn't seem too concerned about existing NL content breakage, there may be an argument for reverting to the traditional RR scale.
But: doing that would cut off a lot of the available range, and then you may end up with demand for a 3rd option to use the current NL RR scale (which would need to range from 50 to 99 instead of 1 to 99 because the traditional scale can't represent these values... unless you want negative release rates to be a thing).
Interestingly, reverting to the classic RR scale would actually fix a minor cosmetic issue in the SI display option, which is that SI >= 100 looks like garbage, but it usually isn't a problem because seriously who uses SI >= 100, that's like 6 seconds at the rate of physics updates. That is, like, EXCESSIVELY slow, and if I remember correctly, these SIs were enabled not because there was actually demand for them, but because they wanted to remove the redundant values in the traditional scale so that changing the RR value would always change SI, so SI from 53 to 102 were created as a result of the scale suddenly having space for 50 extra values. But I'm not aware of any serious complaints that traditional RR 1 was too fast.

Although annoyingly, if you for some reason want a stacker to let no lemmings past it, you need 54 SI which is *exactly* one SI out of the traditional range.

I see no compelling reason not to offer SI as an option even in classic mode (particularly if you don't revert to the traditional RR scale as neither current option is really classic...)

If a climber or a slider is facing left and passes through a permanent skill remover, they will be embedded in the wall.

(For clarity, since Sliders turn: the slider would have been traveling right before transitioning to slider: that is, this always occurs when the skill is interacting with a right-facing wall, thus lemmings interacting with the wall are facing left).

The object works as expected when lemmings are facing to the right.

Another NeoLemmix zoom quirk, but this one might actually be intended: the panel will be located as close to the center of the screen as it will fit when the level's vertical size fits in its entirety, until you zoom in enough to force the panel all the way to the bottom. Thus, zooming in and out can cause the panel to move around.

Lix leaves the panel in place and anchors the bottom of the level to the panel. Personally, I would have expected a similar behavior as well. Still, it's probably worth asking around to see what behavior people expect.

For what it's worth, when NL redefined Release Rate in order to remove the duplicated values in the original, I switched my config to Spawn Interval because I figured if I was going to have to relearn the values, I may as well use Spawn Interval because the definition is very unambiguous about what you get when you use it: the spawn interval is the number of frames between spawns, whereas release rate is an entirely arbitrary scale.

For what it's worth: I use the minimap sometimes, but thanks to the fact that Lix doesn't have one, I know that I'm really not at all attached to it - if it were hypothetically completely removed, it wouldn't take me long to adapt to its removal. That said, it may be more useful to classic mode players who can't just rewind when they miss something.

That said, it should be noted that many people use the minimap for quick scrolling, so it's important that you have a good alternative to it if you ditch the minimap. One possible alternative method that works in Lix is zooming (you zoom out, point at the new spot, then zoom in, though of course this wouldn't work very well without a scroll wheel, but those have been standard on mice for quite some time and I doubt there's many people trying to play the game on a laptop trackpad). This does not work well in NeoLemmix (as Simon has pointed out, not many people have complained about this, and it seems quite likely that a reason for that is just that you can use the minimap instead, and the minimap predates the zoom function).

Many levels these days break the minimap anyway; it doesn't function well on levels that are too tall: a minimap that can't fit the whole play area is unable to fulfill its role in helping to see what's happening offscreen.

I don't understand how everybody else apparently doesn't care and happily plays on. Either everybody else is so thick not to notice any problem, or, more likely, subconciously avoids the nasty zooming even for precision work and just crawls into the screen really close.

Honestly that could be it. I rarely use the zoom function, but weirdly, in Lix, I *will* use the zoom function way more often. Although in fairness Lix levels have a wider variety of starting zooms which could just make it feel like a more natural part of the engine. But it's also completely undeniable that the zoom function in Lix is much smoother than its NeoLemmix counterpart, and generally works exactly as I would expect for the most part until you zoom out too much relative to the size of the level (and idk, maybe that's the least bad solution at that point).

*I've never fully learned what the various points on the splat ruler are, but I know they have something to do with different fall heights for different states. This is way too much for a player to have to bother about; if your level requires use of it, it's probably not a very good level.

I think it has something to do with some very specific weird considerations with splat height from different transition states, e.g. hatch or climbers hitting their heads or something stupid like that. If you're breaking existing content anyway best to find someone who knows exactly what those are and then fix them so the splat ruler can be nice and intuitive like the Lix one.