user30234: My underlying question here is: What is depth?
I know depth is supposedly the number of half-moves or plies from the starting position that it has calculated, in at least one line. But I feel this explanation is not congruent with the result you're seeing here:

I'd expect mate in 7 to be found at depth 14, but I understand it didn't search every line so okay it found it when it had already searched somewhere to depth 21. So far so good.
But, now it finds M13, or mate in 25/26 ply, at depth 21, where it should be at at least depth 25. How?
Furthermore, the depth keeps increasing after finding mate in 13 (ply 26). Why would it keep searching in sequences that are longer than the mate it already found? All subsequent analyses should stay below 26 ply right?



user30239: Because it is not thinking to depth 35 for all moves. These newer engines have multiple levels of thinking. When it says level 35, that means the level of deep thinking. It may only be thinking of 1 or 2 lines to ply 35. Then it works backwards in the tree to look for better moves at an earlier ply. Probably at depth 35 it found a theme which it could used earlier in the tree but had rejected at an earlier depth. Ultimately, when it says depth 35, it is really at that depth anyway. It uses 2 numbers like 24/35. That means that it is thinking of moves at ply 24 but it extends the lines of thinking to ply 35 to calculate the evaluation better. Still, it can only accept so many moves up to ply 24 in order to solve in a reasonable time so it has to sometimes backtrack later when it learns of a new move. For example, there could be a deflection involved. Deflections are not moves the engines normally consider. However, smart engines will discover the deflection later as it serves a purpose to prevent some later move from happening. It then works backwards to find the deflection. This is effectively how humans find deflections, also.

user9192: StockFish at its core uses alpha-beta pruning, as explained in this post. Alpha-beta pruning by itself always gives a correct move according to perfect play, assuming the final position evaluation heuristics are correct. However, SF uses not only alpha-beta pruning, but also many other pruning heuristics that may not be correct unlike alpha-beta pruning, but will greatly increase the final depth that the search can reach. That final depth is what SF means by "depth 35". It does not mean that SF searched every line to depth 35, because it would prune off the vast majority of lines. So if those pruning heuristics are incorrect, then SF may prune off the branch with the depth-7 forced checkmate sequence at lower final search depth.
In particular, the default setting of SF is not to find the fastest checkmate sequences alone but to find the best move in general, because it is much more computationally expensive to prove a checkmate sequence. Whenever SF says #k, it means it searched all the branches necessary to prove that a checkmate can be guaranteed in ≤k moves. But since SF is (wisely) designed not to spend all its time searching for the fastest checkmate sequence, it sometimes fails to see the optimal line because it checked other lines that looked more promising according to the sometimes incorrect heuristics.
That said, I don't know why you say it needed depth 35. Lichess analysis clearly shows that it already found the #7 in the default depth-20 search.

30234: <p>My underlying question here is: <strong>What is depth?</strong></p>
<p>I know depth is supposedly the number of half-moves or plies from the starting position that it has calculated, in at least one line. But I feel this explanation is not congruent with the result you're seeing here:</p>
<ol>
<li>I'd expect mate in 7 to be found at depth 14, but I understand it didn't search every line so okay it found it when it had already searched somewhere to depth 21. So far so good.</li>
<li>But, now it finds M13, or mate in 25/26 ply, at depth 21, where it should be at at least depth 25. How?</li>
<li>Furthermore, the depth keeps increasing after finding mate in 13 (ply 26). Why would it keep searching in sequences that are longer than the mate it already found? All subsequent analyses should stay below 26 ply right?</li>
</ol>
<p><a href="https://i.stack.imgur.com/TckXl.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/TckXl.png" alt="enter image description here" /></a></p>
 30239: <p>Because it is not thinking to depth 35 for all moves. These newer engines have multiple levels of thinking. When it says level 35, that means the level of deep thinking. It may only be thinking of 1 or 2 lines to ply 35. Then it works backwards in the tree to look for better moves at an earlier ply. Probably at depth 35 it found a theme which it could used earlier in the tree but had rejected at an earlier depth. Ultimately, when it says depth 35, it is really at that depth anyway. It uses 2 numbers like 24/35. That means that it is thinking of moves at ply 24 but it extends the lines of thinking to ply 35 to calculate the evaluation better. Still, it can only accept so many moves up to ply 24 in order to solve in a reasonable time so it has to sometimes backtrack later when it learns of a new move. For example, there could be a deflection involved. Deflections are not moves the engines normally consider. However, smart engines will discover the deflection later as it serves a purpose to prevent some later move from happening. It then works backwards to find the deflection. This is effectively how humans find deflections, also.</p>
 9192: <p>StockFish at its core uses alpha-beta pruning, as explained in <a href="https://chess.stackexchange.com/a/29842/9192">this post</a>. Alpha-beta pruning by itself always gives a correct move according to perfect play, assuming the final position evaluation heuristics are correct. However, SF uses not only alpha-beta pruning, but also many other pruning heuristics that <strong>may not</strong> be correct unlike alpha-beta pruning, but will <strong>greatly increase</strong> the final depth that the search can reach. That final depth is what SF means by &quot;depth 35&quot;. It does not mean that SF searched every line to depth 35, because it would prune off the vast majority of lines. So if those pruning heuristics are incorrect, then SF may prune off the branch with the depth-7 forced checkmate sequence at lower final search depth.</p>
<p>In particular, the default setting of SF is <strong>not</strong> to find the fastest checkmate sequences alone but to find the best move in general, because it is much more computationally expensive to <em>prove</em> a checkmate sequence. Whenever SF says #k, it means it searched <strong>all</strong> the branches necessary to <em>prove</em> that a checkmate can be guaranteed in ≤k moves. But since SF is (wisely) designed not to spend all its time searching for the fastest checkmate sequence, it sometimes fails to see the optimal line because it checked other lines that looked more promising according to the sometimes incorrect heuristics.</p>
<p>That said, I don't know why you say it needed depth 35. <a href="https://lichess.org/analysis/4k2r/pp3p2/2p4p/5n2/1PB5/P5PP/5K2/2q5_w_-_-_0_1" rel="noreferrer">Lichess analysis</a> clearly shows that it already found the #7 in the default depth-20 search.</p>
