Noticed a bug in NeoLemmix ages ago but never mentioned it because it seemed so minor and likely only affected me because of the custom panel graphics I use
But now that I know a bit more about how NL works, I wonder if I might be able to help fix it
Basically, if you swap the current “selected button” icon graphic with a paint-bucked-filled semitransparent one, and then hit backwards frame step a bunch of times, the graphic will load again and again, making the pause button appear darker and darker
I’m guessing this might have something to do with Delphi’s need to “free” the graphic…
Because a backwards framestep, as I understand it, loads the replay and plays it up until 1 frame before the current one, then pauses the game
If this is done repeatedly, then the “select button” graphic is getting repeatedly loaded over the pause button
If I have that right, I’ll try to fix it myself and the code can be backported to NeoLemmix

It won't be to do with freeing. It'll be that the selected graphic is redrawn without redrawing the unselected button first (which doesn't cause any issues unless semitransparency is involved, hence why it would have gone unnoticed)
It very likely isn't loading it again either; just drawing it again

AFAIK the pause button is the only one for which this happens, and then only when backwards framestepping. So, it should be easy enough to isolate the code and find a fix.

It may be that the full "redraw original button" is only triggered when unpausing specifically
But for some reason, redrawing the frame is called after a backwards skip

@WillLem adding to what Namida said: in pretty much every 2D graphics libraries I've used, whenever you draw something, it just plops it right on top of what's already there. Thus, the "safe" thing to do is clear the screen and redraw it each frame. But: you can be a bit more efficient if you only update the parts you actually need to change.
Typical NeoLemmix graphics really only use 0 and 255 alpha: pixels are either transparent or they're not, no semitransparency involved. In that case, you plop it on top of whatever was there before, and it looks the same as it would have if you'd actually cleaned up and cleared the screen first (well, at least for everything in that area)
Under these conditions, if you draw the same thing on top of itself, nothing really happens so it goes unnoticed. A little wasteful, but whatever, and hey, it's better than clearing everything and redrawing unnecessarily.
But once you add more options for the alpha channel, now the end color for each pixel depends on its starting color, so it changes every time you do a redundant draw call.
Thus, when redrawing a semitransparent object (sometimes it's necessary, maybe something moved) you need to redraw whatever was behind it too (and even a solid background would count as something behind it)
In this case, though, it's probably as Namida said and it's just being drawn unnecessarily many times, in which case dealing with that's the best fix. If for some reason you can't fix that the hacky fix would be to redraw the button before drawing the semitransparent graphic on top of it.

This is probably something I should fix in NL too tbh. Semitransparency is meant to be supported in most places where it would be sane to use it.