> The corollary to this is that the individual assigned to develop a custom book for an upcoming high-profile engine vs engine event might find alternative lines that are, in practice, "just as good" but not seen often. I believe that is what you were suggesting.

Yes. Playing bad lines makes no sense, but the chess space is so huge that finding playable unexplored variations is not that hard.

>Is this not true also for chess engines (middlegame)?

It is true for chess engines and for all chess entities, no matter how strong, as long as they play imperfect chess. It happens on the opening and endgame too, the only part that has been solved is 6men tablebases and a entity is only expected to avoid blunders in them. This is also hidden by the fact of opposition that is unable to exploit the really bad moves that aren't apparent, but a stronger chess entity (or the same entity with a much longer time control) could.

I use chess engines in interactive analysis for hours in my correspondence chess games and still make such blunders, top correspondence chess players of today make such moves that top corr players from the future would punish and show how bad they are, and as long as chess isn't solved, this situation will remain.

>In other words, when the engine designer/programmer is searching for ways to improve his/her engine code, perhaps the WAY the engine was "thinking" when the mistake was made would be of most concern.

These bad moves are usually product of the horizon effect, no matter how good your evaluation is and how much positions you look at, there's always going to be something outside your horizon, the positions that you didn't analyze, and if the best line was pruned and missed, you're going to play a bad move. This is being fixed by stronger and faster hardware, and by engine evaluation improvements so that the bad variations have more chance of being pruned, but searching some positions means you don't search others, so the bad move is played somewhere else instead of here. The trick is to make it so the positions where the blunder is made are minimized.

Now, I just feel like showing pictures about what I'm saying. What an engine does when analyzing a position is building a tree of variations, my move, opponent move, my move, opponent move, in where the tip of the variation has some evaluation, then, the engine goes back to see if any of the sides could improve on this score by using Minimax, and if it doesn't, it goes to the next iteration. Since the engine is time limited for doing this, what it does it cutting some variations and extending others, so instead of the tree ending looking like a circle like in Brute Force, it looks like this:



This is the engine's tree, the horizon is marked with black outline, in red is all analyzed positions, and in green it's all the chess space outside the horizon, all the positions that there wasn't time to analyze (in reality, it would look with a lot more spikes, but this would be a general shape.)

The longest the spike, the deeper the engine looked. The thicker the spike, the more complex the positions are as the engine had to check for more alternatives of the moves. Slim means the variations are more forced so the engine had it easier to look deeper.

So here, the engine considered 9 main moves and looked at them, the flat line above Root indicates that those moves weren't extended at all, they're probably outright blunders like hanging a piece for no compensation or making a move that gets you mated. These moves are pruned so the north of the chess space is almost unexplored.

Now, let's suppose that there are some truly best moves in the position, those that the strongest chess entity would play, like, the fastest mating moves in a 6men TB. And they go to the end of the game. There's no benefit in deviating from them and doing so would just make their line thinner (until the player misses it and he goes to a losing position). Let's suppose this is a critical position and such a perfect path isn't wide.

On a best case scenario, it'd look like this:



Here, Blue marks the optimal path and purple the positions from the optimal path that were analyzed. This is a best case scenario because the tip of the spike, the position that was analyzed the deepest and from where the engine's score is being brought to the root, is inside the optimal path. The engine has great understanding of the position and it's unlikely it'll leave the optimal path in future moves as it gets wider.

A more normal scenario would look like this:



Here, the score of the engine is inaccurate as at some point it has a blunder in the PV (the blunder is played at the point at which Cyan and red intersect, the engine goes wrong and spends a lot of time analyzing irrelevant positions, here the Cyan part is outside the engine's horizon and it's important), so the score comes from a point outside the optimal play. This, however, is normal, the base of the optimal play was analyzed and an inaccurate move hasn't been made yet, this situation can be seen by just playing the PV of the engine out and seeing a fail low, an inaccurate move is played eventually but the moves near the root are accurate. In future moves it's expected that this is rectified and that the tip of the spike would move towards optimal play.

Now, a blunder:



Here, the engine pruned the best move of the position, and spend too few time on it, causing most of the analysis to be irrelevant. The part in where orange and red intersects marks the point in where the engine missed the critical move near the root, and then spent most of its time analyzing variations that it mistook as better. Depending on what side the engine is playing, it means it's going to play a game losing blunder and miss the winning move against it, or that it had a win on its face but missed it due to wrong evaluation. This is why interaction is important, to avoid this a user just needs to force this move to increase this horizon and have the key move inside the search.

Now, the improvements made to the engine in this position could have different effects. More hardware or more time would make all these spikes a little bit longer and thicker, making the tree bigger, and eventually, the small north spike would find the key move and the analysis could focus on the optimal line. Better search would make the spikes sharper, and would make the bad, irrelevant spikes shorter, which would give more time to the ones of the best moves, so the key move is found faster. Better evaluation would make the tree look more like this at earlier depth:



Since the key move would be found faster, most of the analysis focuses on it and the rest of the moves get less time from the engine. However, more knowledge means the engine is slower, so it can't analyze as much positions, so on other positions the tree wouldn't get to grow as big and would miss the optimal line. There's a tradeoff.

So in the end, these kind of blunders aren't of the highest concern, what will improve the engine most will be decreasing blunders overall (no matter what type of blunders they are.)