the problem you are talking about is known since 20 years. It has the name "Graph History Interaction" - Problem.
I like your example:
[d]4k3/b7/8/7P/7P/7Q/r6P/5K2 b - - 0 1
I am wondering that nobody here seems to know anything about it, but anyway there are a lot of documents written about it, e.g.Uri Blass wrote: imagine that your program got the following position in the search
[d]4k3/b7/8/7P/7P/7Q/r6P/5K2 b - - 0 1
imagine that the program searched
Ra1+ Kg2 Ra2+ Kf1
Do you store draw score for the position after Kf1
Draw score is not correct because white is winning by Ke2.
...
Uri
http://www.google.com/search?q=graph+hi ... nteraction
If you like to read, be sure to read this:
http://www.fun.ac.jp/~kishi/pdf_file/AA ... imotoA.pdf
They claim to have developed a efficient, general solution to this problem, _but_ they are mainly interested in and/or-graphs which they search mainly with proofnumbersearch. Their solution works in alpha-betasearch too, but they doubt if it is that essential there.
Basically they do the following:
They store for every position a hash of the path from there this position was reached. This can be done efficiently using zobristkeys, as everyone here knows. Later, then the position has occured again, they check the hashes of the path. If they agree, they conclude that the pathes are identical and retrieve the value. If they differ, they research the position to calculate the true value. But since they have already searched this position they do that in a special manner coined "simulation" to reuse information in the hashtable as much as possible.
What is your opinion about the feasability of this method to chessprogramming?
Oliver