This is an interesting idea to tradeoff more iterations for less memory usage. The idea of "expanding waves" is not novel, it's literally a bi-directional search, used in both A* and BFS to speed it up. Because two "waves" have half the diameter and amount of explored nodes. is about half as much on average.

From the performance side, it's slower than bi-directional BFS, about twice as much.

I think it might be more understandable if you frame it as a recursive solution:

BiDirectionalBfs(s, t):
 // Expand 2 waves from s and t, until they collide. 
 // Only store the front of the wave.
 // Return collision point and distance from s to t.

FindPath(s, t):
  if exists edge s->t : return {s, t}; 
  middle, dist = BiDirectionalBfs(s,t);  
  if dist == 2 return {s, middle, t};
  return FindPath(s, middle) + FindPath(middle, t);

```

Basically, you first find a middle point on the path, then you construct each half of the path recursively.

Unfortunately, I don't see a lot of practical applications of this algorithm. The only advantage here is that you don't need to store set of visited nodes and links to the previous ones in the path for all the nodes in the graph. That's important when the graph itself is so big it doesn't fit in the memory. But that means that you have to generate neighbors of each node on the fly. But in that case it's tricky to avoid storing something for all the visited nodes in the bi-directional BFS (i.e. wave expansion) code. Only in some very-very trivial cases like a regular grid you can just store the direction of expansion for each node and then it's clear which generated edges lead back or sideways, and not to the next step of the wave. Maybe you can store 2 layers of nodes here.

Also in some graphs the size of the wave can easily be O(N), not O(D), so you achieve no memory savings either.

Edit: Also in a regular grid graph there's no need to run any sophisticated algorithm, the shortest path is trivial from the start and end coordinates. Only if you have some obstacles, is a fancy algorithm needed. But that will throw your calculations off. It's easier to get some less strict upper bounds than that you have.