Detailed explanation

Sokoban can be seen as a type of maze where the goal is to reach a target state from among all possible states (arrangements of boxes). Abstractly, all possible states are nodes in a graph, and states that can transition between each other are connected by links. This is difficult to explain in words, but there is a good visualization in the video  https://www.youtube.com/watch?v=rTkW4OPj5eg 

However, there is an important difference from a typical maze. In a regular maze, if you go down the wrong path, you can simply turn back. In Sokoban, state transitions are one-way and irreversible. In short, you can push a crate, but you can't pull it.

You might think that if you make a mistake and push a crate, you can just use "Undo" to return to the previous state. However, there is a clear distinction between being able to reverse an action and being able to perform an action in reverse. This is precisely the distinction this game explores.

In this game, the character has a "forward" state and a "reverse" state. A character in the forward (or reverse) state can only move along the directed links of the graph in the forward (or reverse) direction.

This is different from an undo function. With an undo, you have to retrace the exact path you took to go back. This game has no such restriction. To put it in a fancier way, by returning along a different path than the one you came from, the player can travel to a different timeline.

Finally, I must mention a subtle point that I had to compromise on when creating this game. This subtlety is already present in the most basic action: pushing a crate.

First, let's consider a state like this:

[ Player | Crate |     ]

For convenience, I'll use a syntax similar to PuzzleScript, though it's slightly different from the actual implementation.

If you press right in this state, you get:

[ > Player | Crate |     ] -> [     | Player | Crate ]

The crate is pushed. The reverse transition for this would be:

[     | < Player | Crate ] -> [ Player | Crate |     ]

This is the same as the player pulling the crate. Simple enough.

But wait! You could also have a move like this:

[ > Player |     | Crate ] -> [     | Player | Crate ]

Playing this in reverse means that pressing left should result in the following transition:

[     | < Player | Crate ] -> [ Player |     | Crate ]

In a normal undo system, this redundancy is eliminated by keeping a complete history of the gameplay. That is, you can't go back to the past just by being given the current state of the game and a sequence of inputs (u,d,l,r); you have to rely on memory at the point where the redundancy occurred.

This game does not record history. Therefore, to uniquely determine the reverse transition, I had to arbitrarily choose one transition that I felt would make for a more interesting puzzle.

In the previous example, if I had adopted the latter reverse transition, a player moving backward in time would be completely unable to interact with the crate. Therefore, I decided that the player should be able to pull the crate. But there is no general principle behind this choice; it had to be an ad-hoc decision.

Seriously thinking about how to solve this problem could lead to the birth of a new kind of puzzle. However, in a puzzle game, one should probably avoid getting too theoretical and straying too far from intuition. In any case, my own thoughts are not yet fully settled.