I think any of No, Cancel, or Delete work fine in this case.

The "Delete" option is already likely as clear as it possibly can be, and conveniently, that's the important one. From context, it's easy enough to deduce that "No" means "Don't Delete" (although I suppose "Don't Delete" is another wording you could consider; a bit lengthier, but abundantly clear), and I don't think anyone's going to say "Hmmm, I definitely don't want to delete this level, but I'm a little unsure of what "No" means here, so I'm going to push the button that says "Delete". That said, thinking about it, "No" is probably the least good option here (out of what has been presented), but least good != bad.

Simon correctly deduced that I didn't vote in this poll, and I can see from the timestamps exactly how long it was open. I can never remember if the forum software gets my local timezone right, though, so I can't be certain what I was doing during that time, but I think we can all agree that it's a little silly to not get your voice heard because you were busy with something else when the poll happened -- it's not like I knew it was coming ahead of time to be able to make time for it!

Simon has already touched on making sure you understand how you're interpreting "no" votes. He correctly notes that "You ask X if X wants Y, the answer is no, then you draw the conclusion that X wants Z to not have Y." You at least had a "don't care" option, but that doesn't necessarily mean people won't just vote for their preferred option. If we're debating if something should be an option or not, and I already prefer the default, then there's not a strong incentive to keep that option alive because I get what I want regardless. Sometimes it's worth fighting against the option, if you can make a case why the option is a problem (e.g. the old debates on having direct drop as an option for the user or developer, where the inconsistent engine behavior can lead to problems with level design), but I don't think this is one of those times, as SI vs. RR is purely cosmetic.

Generally, I'd say 24 hours is a minimum time you should leave a poll open, and ideally probably a week. There forums don't generally move very quickly, so it's quite realistic to expect many people may only check once a day; maybe a few times a week; or even once a week! Only call it early if it's extremely one-sided, and err on the side of caution (if in doubt, don't close early). You may have thought this poll was one-sided, but it wasn't open very long, and there were only 3 votes. If a high ratio regardless of the number of the votes is the sole criteria for deciding when to call a poll, then you may as well just close every poll after the first vote, because 100% of people who voted picked whichever option the first voter picked.

I could probably make a case that you closed the vote early because it showed the result that you wanted, and I'm not sure a reputation for biasing feature votes in your favor is something you want if you want your development journey to be relatively drama free.

---

Incidentally, I believe I asked you a while back what your design philosophy for SuperLemmix was, when I was suggesting you should really decide who you're targeting this to instead of trying to make everyone happy, and you said you wanted to try to make everyone happy.

Now, making everyone happy is pretty much impossible (see: timed bombers), but you're now actively failing what's pretty much a freebie test: you say you want to try to make everyone as happy as possible, and then you go cull some random harmless cosmetic option nobody complained about that wasn't causing anyone any problems because you don't like using it.

For what it's worth, I think there's a strong argument for 16:9 as the standard aspect ratio, *but* I don't think it makes sense to force 16:9 as long as the panel physically fits at x1 zoom for the currently selected resolution (as in high-res vs. low-res graphics). I don't think you're implying that you would do that, but I wanted to state it explicitly.

Because the 160 pixel level height is so common, I think it's a good reference point for the level size. It's kind of arbitrary, but I figure there's enough existing content that there's a strong argument for keeping the tradition unless we can really clean up the layout by making the default something else (I feel like it looks nice when the default height fits exactly, personally).

I thought of a possible problem with my number crunching that may affect you that I didn't think of: because I prefer the original pixel art graphics, I completely forgot about high-res mode, which could affect what zoom levels look good. (I can probably still make that many buttons work, but I might have to redo the overall sizes if e.g. x3 or x5 zoom levels look bad when using that mode: if you use high-res mode, it would be helpful if you could give an opinion on how those zoom levels look -- assuming high res mode doesn't just not allow those levels).

In case it is helpful: The Lix default for windowed mode is 1280 x 720. This size seems pretty reasonable for a windowed mode; would recommend trying to make the panel work at this size if at all possible.

Lix doesn't have a minimap though, which probably helps a lot to make everything fit.

I agree you probably don't want to deviate much from the standard aspect ratio if at all possible. Ideally, windowed mode is just like fullscreen mode, but smaller.

We All Fall Down.

The solution is of course trivial, having been designed for the original game as an extreme example of a level where doing the solution is where the difficulty comes from rather than figuring it out. But from that regard, really only the Mayhem and maybe the Taxing versions are "interesting" in the sense that they may require a slightly different solution just to be reasonably completable, although NL framestepping tools show that the level DOES actually have enough space to do the trivial solution, if you can somehow pull it off without those player assists. And ultimately the thing that you have to do to be able to pass it isn't very interesting; it's just finicky because it's easy to have to start over because of a single very slightly mistimed input.

Some thoughts:

If you're going to do this, it's quite clear that you don't really intend on following the existing NeoLemmix philosophy in regards to the player assist mechanics, and I'd have to question if it makes sense to appease both crowds with this engine. Perhaps fully embrace this engine's difference in philosophy and then design a cohesive experience around that. If we still want to maintain the existing philosophy, there's no reason we can't make divergent forks.

As part of this, rather than allowing levels to disable player assist features, I think it would be better for you to decide which player assist features this engine should keep. As a general rule, I'd suggest definitely keeping the player assist features that multiplayer Lix allows you to use:
 - Directional Select. It only breaks one official level, and that one level has a trivial solution and is at worst a 1 in 8 chance to solve correctly if you don't even try to get the timing right. It prevents you from having to redo a level simply because, for example, you had to pick a lemming out of a crowd and you got unlucky (in practice, there's no RNG going on, but the way small differences can affect the exact alignment of lemmings may as well make it RNG). Additionally, a few of the official ports support it.
 - Splat Ruler. Not even remotely game breaking even on levels with trivial solutions that are just finicky to pull off.

In addition, I recommend keeping Clear Physics Mode just because let's be honest hidden objects suck and it doesn't actually make fair levels easier.

The rest I'll refrain from commenting on for the time being. Though I do hope you at least keep pausing with a hotkey even if you don't keep assign while paused. There's precedent, lots of the official ports support it.

Why disable auto screen start? That's not a player assist feature, that's a designer assist feature. You leave auto screen start on and it chooses a sensible starting position for you, and then you override it in the editor if you don't like what it chose.

I may be one of the less active designers, but my general rule with it is that I look for the main ideas from the intended solution being there. Many backroutes barely engage with the level at all and are worth patching for that reason alone. Some are interesting in their own right, but they still can steal the spotlight from the intended solution which was also presumably interesting enough to want to showcase in a level, so I think the best approach there is to patch and then recycle the backroute into its own level.