Nein, Peter, glaub ich nicht, aber unter 40 Zügen glaub ich auch nicht, dass es 1-0 wird.
Ich steigere mich hier nur deshalb wieder so hinein, weil ich es als Beispiel verwenden will, wie ich Stellungen charakterisieren würde.
Ich finde, das Hauptkriterium, und ich glaube sogar das einzig wesentliche, was das Herangehen mit mehr oder weniger Nullzug, sowohl für engines als auch für Menschen (mehr planend, "Nullzugkaskaden", oder mehr rechnend, Zug-um-Zug, Umstellungen berücksichtigend), ist die Dynamik, die in der Stellung liegt.
Diese Dynamik ist so schwer definierbar eigentlich gar nicht, es ist eine reine Frage von sozusagen Tiefe mal Breite, wieviele Halbzüge dauert es, bis ein eindeutiger Vorteil für eine Seite da ist, (wie schnell entwickelt sich der Vorteil) und wenn der schon vorliegt, wieviele Züge sind's noch zum Gewinn (Tiefe), und wieviele Varianten muss ich dazu von welchen Halbzügen aus durchrechnen. (Breite, wie sehr forciert oder unforciert sind die Abspiele.)
In dieser Bewertung der Dynamik einer Stellung liegt eigentlich schon alles über Taktik und Strategie, über forcierte und positionelle Varianten drin, über "Weiß gewinnt", hält remis, Eröffnungs-, Mittelspiel- und Endspielstellungen, "Stellungsbilder" kann man dann immer noch eigens beschreiben, die sieht man aber ohnehin, wenn man die Stellung einfach nur anschaut, oder man sieht sie eben nicht.
Und auf code- Ebene ist es bei den Programmen ja auch nicht die Frage, was könnte mal alles an "Wissen" einprogrammieren, sondern wie wirkt sich diesbezüglich hardcoded knowledge aus, es ist keine Frage der statischen Eval, denke ich, die wird wohl durch möglichst viel solches Wissen immer automatisch besser werden, in allen Stellungen, die Crux ist, dass die Suche dadurch immer verlangsamt wird.
Der Programmierer braucht also nicht möglichst viele "Stellungsbilder", wie auch immer man die katalogisieren wollte (praktisch unmöglich, da auch nur zwischen menschlichen Spielern auf Topniveau irgend eine Übereinkunft zu treffen, "weiß Botwinnik, wie Botwinnik denkt?"), er braucht Kriterien, die die Stellungen objektivierbar und reproduzierbar unterscheiden, auf der Basis der Stellungstests braucht er Stellungstestmethoden neben dem reinen eng-eng-play out, wenn er denn meint, dass er sie braucht, ist er nur an Elo interessiert, braucht er sie vielleicht ohnehin nicht, weiß ich nicht, muss der Programmierer wissen, hören tue ich halte immer wieder, dieses und jenes sollte meine engine können, auch wenn's vielleicht keine Elo bringt und noch wichtiger heutzutage: woher soll ich wissen, was ich probiere, auch um die Elo zu steigern, wenn ich erst durch Unmengen von Partien noch Elosteigerung nachweisen kann, sollte ich mir die patches vielleicht doch auch ein bisschen schachlich überlegen, bevor ich die Hardware- Lawine wieder lostrete.
Und dann ist meines geringen programmiertechnischen Wissens nach, die Gretchenfrage nach wie vor die: wieviel pruning (und der Nullzug spielt, sage ich, immer noch die größte Rolle) verträgt welche Stellung, das ist genau die Frage, die rein und allein nach der Dynamik der Stellung beantwortbar ist, so wie ich sie für mich definiere.
Während engines statische und dynamische Evals haben und beide die Suche bestimmen, schaut der Mensch eigentlich meinem Gefühl nach auch genau so: ist das eine Stellung, die man durchrechnen muss, gibt's da taktischen Pointen, oder ist das eine Frage von "Strategie", heißt zuerst planen, dann rechnen.
Eine gute Studie zu lösen, hat der Mensch z.B. kaum eine Chance, wenn er nicht weiß, dass es eine Studie ist.
so ein schönes und ziemlich genaues Beispiel 
CSS-Shop