cuBerBruce
Member
Yes, the program forbids quite a few pairs of its own. The reason for the problem you encountered is that ksolve+ has apparently already forbidden UB FL due to the two moves being parallel (it always forbids one of the two possibilities when it notices this). When you manually forbid the other possibility (FL UB), it cannot generate UB and FL next to each other in either order. Your move sequence is also equivalent to FL UF UB, which I think is also forbidden by the parallel move code. Thus the 3-move solution is blocked. I think this is more of an unintended effect of your command than an actual bug, since it seems like ksolve+ is working properly given its internal list of forbidden move pairs. I'll add some code to deal with this case, but you should never need to use ForbiddenPairs in the way you did.
So basically, while the original ksolve gives the user full control over defining canonical sequences, with the new version the user don't have any control over that whatsoever. I think it's great that the program can handle canonicalization automatically, but I don't think I particularly like its choice being forced upon me. And it seems to me the ForbiddenPairs feature has been made pretty much obsolete unless you want to prohibit certain non-commuting 2-move sequences for some reason.