*lol* OK, you're right! I just set up a formula to calculate an upper bound for the number of possible different moves for one move. Let w be the protein width, h the protein height and m=min{w,h}. Then the number of possible moves for one move is
\sum(i=0, w-1) \sum(j=0, h-1) ((w-i)*(h-j)*3) = 3/4*w*h*(w*h+h+w+1)
for Inv, FlipV and FlipH plus
\sum(i=0, m-1) ((w-i)*(h-i)*3) = 1/2*m*(2*m^2-3*(m-1)*(w+h+1)+6*w*h-2)
for Rot90, Rot180 and Rot270.
So for a 32*32 board we'd have a maximum unsolved protein size of 32*31 => 785664 + 32736 = 818400 possible moves for the next step.
As we search for a minimum number of moves and we already know that this number seems to be less than 300 we could very roughly approximate the number of moves to be taken into account at total by 818400^300. Well, that's really a bit too much ;D
With s being the board size (in our case 32) better approximation summing up over all protein sizes, assuming an average of c moves per solved edge and using k as number of move types would be
\sum(w=2, s) \sum(h=2, s) (c*1/4*w*h*k*(w*h+h+w+1)) = 1/4 * c * k * (s*(s+1)*(s+2)/3-2)^2
As the rotation moves take a minor role in the number of possible moves, we assume k to be 3. Also we set s and c to 32. Then we get 3,436,443,744 moves to consider by the optimum searching algorithm. Hm, that's MUCH less than the above 818400^300. Still it would take quite some time, and with a breadth-first search you'd need quite some memory. If you use a depth-first search with some upper limit per edge to avoid getting 818400^300 again, memory wouldn't be a problem, as each move is reversible, so you just needed one board.
Well so much for this completely useless calculations ;D