I've already stated my reasoning in more detail in Discord, but summarizing here:

While the NeoLemmix behavior may not neccesarily be what newcomers would expect, it only needs to be learned once. After that, it is completely unambiguous: there is no guesswork as to exactly what is and is not steel, and thus no nasty surprises once the player has learned the rules. Any other reasonable behavior means that every instance of overlapping terrain + steel must be assessed individually and/or that CPM must be used to ascertain the steel boundaries.

Thus, the existing NeoLemmix behavior is the best solution.

---

That said, I get the desire to be able to decorate steel. Simon's proposed solution is a good general solution, I think, though presumably two adjacent steel tiles should be treated as one for this purpose.

A simpler alternative might be to allow styles to mark some pieces as being primarily decorative, such as moss pieces in orig_dirt. These pieces could be overlaid on steel and wouldn't turn it into non-steel, while normal terrain pieces would. It would be less consistent, however... but presumably there wouldn't be particularly many pieces marked as such and it would be obvious something weird is going on if someone tries to abuse it (this assumes that standard styles get vetted to make sure the choices they make are reasonable, of course, but new styles aren't super frequent so I don't think that will be an issue).

I would like to make it abundantly clear that I'm not talking about conversions of NL -> SL content. For the purposes of this discussion I'm assuming that NL content is expected to break. Existing content, here, thus refers to existing SL content, whether it be levels that people have already made for SL, or NL content that has already been ported.

---

I feel like you kinda side-stepped my point a bit.

My main point is as follows: You should have an idea of which features are still subject to change and which ones are pretty much set. Currently, the impression that I've gotten is that EVERYTHING is on the table. If you wanted to make a SL level without worrying about if you're gonna need to make a ton of maintenance updates and even full level reworks down the road, which subset of features are safe?

It's not too important if you aren't sure exactly what specific changes you want to make; but you should know, for example, which skills/objects/mechanics/etc. are you considering making changes to?

Keep in mind that there were very few breaking changes in NL history *because* of the existing content attitude. There certainly were some, but they weren't something to be taken lightly. We did it on a few occasions when we decided the benefits outweighed the costs, that's true, but we also weren't constantly discussing a new set of breaking changes every week or so (except arguably the infamous culling frenzy, but they were also pretty grouped, like, if we're going to do breaking changes, let's do a bunch of them at once... and they weren't without controversy at the time).

Generally, we don't want to be constantly revisiting old levels to update them for breaking changes. It takes away time that we can use for other things, like making new levels, or literally anything other than updating levels that were broken for no reason. So when you do break levels, you should have a good reason for doing so.

I don't have many levels out there, but I should probably comment on this here:

I discourage (but won't outright ban) unofficial SL conversions of my content. Because of the extensive number of differences, I simply cannot guarantee compatibility.

If you choose to port regardless, here are my boundaries:

• You must make it clear that it is an unofficial port, that is
  • I wasn't the one who did the conversion
  • Issues with the conversion should be reported to its maintainer and not to me (unless those issues are present in the originals)
  • The levels were intended for their original engine (presumably NeoLemmix)
• If the level does not have a time limit, do not add one. If WillLem culls the infinite time option: Set the time limit to the maximum value allowed.
• If the level is made for an engine that requires time limits (and thus has a time limit), the time limit should be removed.
• I don't have any worthwhile vanilla Lemmix content that has tight time limits, so don't bother guessing if it should have one or not.
• If the level was made for an engine that does not require time limits, then you can keep existing limits (there probably won't be any levels like this)
• If in doubt as to whether the level is intended to have a time limit: just remove it
• Always use untimed bombers, even if it's old Lemmix content that would have had timed ones when it was created.

I thought I'd let you know this is a thing, but it's up to you if it's worth the effort or not: apparently, if you make a highlight out of a VOD, the VOD will still disappear after 14 days but the highlight won't; assuming they haven't changed anything about it since I tried it and just didn't update the system to delete the old highlights, as far as I know there's nothing that stops you from making a highlight that's just the entire VOD.

Is there a specific motivation for wanting to use the DOS version specifically? You may have better luck with Lemmix (or NeoLemmix if you don't mind enhancements/bugfixes). Probably using NeoLemmix (or, if you insist on timed bombers, SuperLemmix) is your best option; you can choose to either use the new stuff or ignore it and just use the old stuff.

The version of DOS Lemmings I have lying around says the BILLANDTED code is incorrect, *but* it seems to still work correctly (after entering the code and then starting levels as normal, press 5 on the numpad); it just doesn't TELL you that it accepted it. It's not good for custom content for other reasons, though... I think OhNo works a bit better, but I think there's a version of the original that might work better called LEMRMAKE.EXE if I remember correctly. But I don't know what the level skip code is in that one.

There's also CustLemm but the physics are kinda messed up.

First relevant point: Was the save requirement met?
This factor may very well affect the desired behavior! Generally, we don't want to have to manually end completed levels, but having the option can be nice when trying to optimize. We're not always trying to optimize, and probably not trying to optimize most of the time, so while we want to be able to accommodate this use case, the defaults should probably assume the player would like to move on when the level was successfully cleared.

---

Obvious end states (regardless of save progress):

There are no lemmings remaining.
There is no time left.
Only zombies remain.
All remaining lemmings are blockers with no way to free them (note: this specific case may be a niche for auto-nuke since they don't move and it's the only possible move).


Potential other case to consider (trivially-detectable soft-locks):

Too many lemmings have been lost.

---

Further thoughts:
In general, when one of these end cases is reached, if the save requirement has been met, the level should end unless the player explicitly chooses otherwise in the settings menu; if not, gameplay should pause or continue (or have an option), see specifics. Since we have the option to rewind, having the level forcibly restarted is no longer the obvious choice it once was. For clarity: the instant the save requirement is met is NOT an end state and should NOT auto-end; it's merely a milestone that affects what behavior we want to see when the level would end through other means.

When we have the option to pause, continue, or end the game: I think the player should have the option which one to prefer. If they prefer continuing, specific cases should force pausing (specifically, when physics can no longer meaningfully advance; i.e. the physics are unchanging).

There are no lemmings remaining. Should probably block further physics updates to reduce rewinding; there's no benefit to allowing the game to progress in this state. But, not ending the level means that you can rewind from this state, unlike the current behavior where this case always ends the level.

There is no time left. I think it's reasonable to want to pause or continue in this case. Should probably be an option. May want to consider combining with the other "soft-locking" case, where the save requirement can't be met due to losses.

Only zombies remain. If you pause in this scenario, there IS a reason to want to resume, as you may wish to watch the movement patterns of the zombies.

All remaining lemmings are blockers with no way to free them. I'd actually say this specific case should result in an auto-nuke and then proceed to the case There are no lemmings remaining to determine further behavior. No way to free the blockers = no walkers or bombers remaining. We want to auto-nuke since technically, the nuke could free one of the blockers which probably won't get it to the exit, but in theory it could.

Too many lemmings have been lost. It may be worth having an option for, and it's arguably a similar case to time up. Still, though, I think there's arguably a major reason we might explicitly not want to pause in this situation even when we would want to pause in other conditions: replay insert mode. When you have stuff happening in multiple spots on the map, sometimes it's convenient to just completely ignore all but one part of it, do what you need to do there, rewind and replay insert.

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...)