I thought of another idea, to introduce enemy units so it gains a similarity to chess endgames but it would be a lot of work.

Actually, the thing that stops me from leaping to implement this is not the amount of work but a few small problems which I can't decide how to resolve.

1) If the enemies move in a phase after the player's move, then the player's apparent visual move speed is halved, which could feel very unpleasant, but maybe it's okay because those levels will be considered 'unsolved'?

If the enemies move simultaneously in time with the player, then collisions become visually confusing because there are two kinds of collisions now, starting from adjacent and from a 1-tile gap.

2) Worse, while the AI movement could easily be designed in a deterministic way, it's very difficult to communicate to the player which direction gets priority in diagonal cases where both moves seem equivalent.

I don't think the player is likely to internally model a fixed move order priority, and even if that information was displayed visually, I would not feel good about using it to solve a puzzle.

Additionally, if I made the AI favour minimising Euclidian distance from its target, it would mean the AI is no longer consistent with the player's click to move pathfinding unless I recalculate the path whenever the player clicks to queue moves. That might be an option but it's inconvenient.

3) I want to show the reachability of units by hovering them, but I don't know how to display this visually.

If it overrides the default active player's reachability saturation, then it's going to be confusing and make you think you controlled that character, as well as worsening experience in the valid and common use case where you click a unit intending to path to and pair up with it.

After writing this out I had the idea for 2) to show an arrow for the AI's projected move when you hover the map with the mouse, as well as the player's projected move.

But it would only be for the next turn, not all moves in the sequence to reach the hovered tile, because the predictions would become inaccurate.

Even though keyboard moving is also allowed, the player can choose to use mouse movement in situations where precisely predicting the movement of an enemy is important.

It's not ideal though because the player should be required to calculate in their head and predict exactly what will occur, a vague uncertainty requiring testing isn't good.

Maybe I need to make an effort to teach them priority through level design? But most players would guess or brute force it because there's only 2 possibilities.

Since I optimised the pathfinding algorithm, I should be able to run it multiple times in one frame.

This will take a lot of refactoring, I'll give it a rest for now.

I still didn't solve 1) or 3).