Nope. Going backwards isn't nearly as easy as fast forwards.
What it comes down to is - for fast forward, in reality if the game was left to run as fast as your PC could handle, it'd be, well, a lot faster than it is now. There's code specifically to limit the speed; fast forward simply increases that limit (in most cases, the speed limit is still the limiting factor, though in intensive situations and/or weak PCs* you might find that fast forward mode is further limited by your PC's power).
Now on the other hand, processing in reverse isn't the same. For example, let's say we have a walker walking to the right along a platform. How do we reverse him one frame? Your first reaction might be "easy, move him back one pixel" - but how do we know that's correct? Maybe he didn't walk from the left - maybe he fell from above and this is his first frame after landing. Maybe he was a blocker who just got assigned a walker. Maybe he just stepped out of a teleporter. Maybe he's just been cloned from a lemming that's walking left, and didn't even exist on the previous frame. Etc.
Instead, backwards framestepping is achieved by loading or re-generating an earlier, known state, and then doing a forward skip from there. Lemmix and very-early-NeoLemmix used a very primitive method - reload the level altogether, then frameskip forward to the target frame. Lix and modern NeoLemmix use a smarter method, where the level's current state is saved every so often (the two differ in terms of exactly what states they keep - in particular, Lix's are selected in a way that is beneficial to multiplayer mode too - but the basic idea is the same), and whichever one of these is most appropriate will be used.
So - this means that any reverse-direction gameplay would mean the game has to constantly load these states and step forward, to one frame (or 4 frames, if that's the interval, etc) each time. At the finest level, NeoLemmix takes states every 10 seconds, so this means between 1 and 169 frames need to be processed, as well as a state loaded, for each backwards step. It only keeps the "each 10 seconds" states for about half a minute; once you go so far back that you've exhausted all the currently-in-memory 10 seconds states, it's now relying on the 30 second ones, and then eventually 1 minute ones (per-minute is the longest gap NL ever has between save states, no matter how long gameplay goes on for). When we get to the 1 minute interval, that's potentially as many as 1020 physics frames being processed for each iteration of backstepping. When doing this once or twice, or when speed isn't expected, isn't much of an issue (especially since in these cases you're not likely to go beyond even the 10 second interval snaps, let alone the 30 second interval ones). When you try to implement a reverse time mode, that becomes another story.
And that's without going into that entirely new code outside the current timekeeping / stepping would need to be implemented, in order to handle a continuous-backstep mode - currently, there's only support for "jump back to a specific point once then pause / continue as normal", "pause", or "go forward at an arbitrary speed, subject to limits of PC's power" (for which 3 speeds are defined - normal, fast-forward and slow-mo).
So yeah, tldr: while I have no objection in terms of whether the feature would be worthwhile, I'm going to have to reject this one on practical grounds.
* what really matters is RAM speed and single-core CPU performance
