Polyominoes are made by gluing together finitely many squares along their edges. They always have connected interiors, but are allowed to have holes.
Enumerating polyominoes is a huge subject, and of course the answers depend on whether you are interested in free, one-sided, or fixed polyominoes. I am trying to understand one of the most fundamental algorithms in this area, although I'm aware that faster, but more complicated, algorithms are known now.
Specifically, I'm interested in Redelmeier's algorithm for enumerating fixed polyominoes:
https://en.wikipedia.org/wiki/Polyomino#Algorithms_for_enumeration_of_fixed_polyominoes
You can find the original paper here: https://dx.doi.org/10.1016%2F0012-365X%2881%2990237-5
And in case that link is behind a paywall, the algorithm is described in Section 2 here: https://arxiv.org/pdf/1106.1078.pdf
I am having trouble understanding the recursive description of the algorithm in the original paper, and I find the Wikipedia description much easier to understand. Unfortunately, I am not sure if what is on Wikipedia is correct. What is bothering me is that the algorithm described can get stuck sometimes, where no further tiles can be added to the current polyomino. (In fact, if you try to generate a "random" polyomino with 1000 tiles, you will almost always get stuck at some point.)
The smallest example I have is illustrated below. This seems to follow the rules described on Wikipedia, but now we are stuck.

I am also struggling to understand the details and must also conclude that the paper is just not written very well. It doesn't properly distinguish global state from local, for example.
Wikipedia makes a nice try with the numbers, but the devil is in the details, which aren't mentioned. Once I get my head around it, I may improve the Wikipedia page with pictures. For now though, I think I can answer this question.
This "getting stuck" also happens with the original algorithm. It's not a problem: your recursive calls simply return without generating any new polyominos, until a call higher up the stack can continue somewhere else. Note that Redelmeier's paper mentions in the text above the pseudocode:
In some cases, a recursive invocation would receive an empty untried set right off the bat, and so it would return without doing anything at all. Then the parent call would continue with another neighbour.