@purgency. No, it cannot. In fact, I suspect that misere cannot be solved at this time.
@Carroll. Thanks for reminding Bill to re-visit my tie-breaking algorithm. His intention was, as you suggest, to play the "hardest to respond accurately to" move.
My basic algorithm is to choose randomly among all moves which guarantee the current score, but to assign them different weights. The idea behind this was to provide a greater variety of games, so that I don't get stuck in a rut (which could be exploitable). Also, the humans I play against seem to find variety enjoyable in its own right -- go figure.
There was a bunch of code which involved making sure I could make "my moves" in the opening even if there were "better" moves out there. It did this by assigning weights of 1; 10,000; 1,000,000;, and 100,000,000 to various moves. (This applied during the first 8 moves. Bill is going to modify it so that it applies during the first 8 moves only when the position is not in the database, which should be never).
If I am behind, I assign higher weight to moves as the number of losing moves by my opponent increases (2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96,...). I am happy with this one, despite the fact that it is possible that someone could find a line against me which not only wins but where I am likely to play it again next time.
If I am tied or ahead, I give all moves equal weight. An additional advantage to not always playing the trickiest move here is to avoid discouraging people by running up the score. Bill could also add a "bloodthirsty" mode which assigns weights in the same manner as when I am behind.