Memoryless depth implies that depth contents would be discarded on render target change. What is happening here, is that we first render camera without shadowmap (so it just renders to backbuffer directly), and then the camera with shadows is rendered. This second camera first render shadows (here the render target change is happening and the depth contents are discarded) and then renders to backbuffer depth. In xcode frame capture, in both 22.3 and newer unity version, you can see that the depth buffer is filled with NaN values (as expected) so any depth comparison operation result is subject to a lot of things (maybe even including moon phase! who knows). Joking aside, the fact that it renders "fine" on 22.3 is a pure accident: for example when checking rendering in frame capture you can clearly see that rendering is different from the "normal rendering on device". There are several possible workarounds (maybe not viable in the full project):
1. Second camera can clear depth (this is "free", so no performance impact) - it will make sure that depth is filled with non-NaN values, making depth comparison predictable
2. This is more specific to repro, I would say: you can reorder cameras so that shadows rendering happen in the first camera; then actual rendering for first and second cameras can be shared (but this approach is quite fragile, I must say)
3. You can switch to URP+RenderGraph which would make these decisions (having memoryless render surfaces) with full knowledge of global usage of them

To summarize: memoryless depth backbuffer is well suited for the setup of "one camera renders to backbuffer the final result" since this avoids all these potential pitfalls. Indeed, the fact that camera renders shadows before doing "normal rendering" does not interact well with memoryless depth

Memoryless depth implies that depth contents would be discarded on render target change. What is happening here, is that we first render camera without shadowmap (so it just renders to backbuffer directly), and then the camera with shadows is rendered. This second camera first render shadows (here the render target change is happening and the depth contents are discarded) and then renders to backbuffer depth. In xcode frame capture, in both 22.3 and newer unity version, you can see that the depth buffer is filled with NaN values (as expected) so any depth comparison operation result is subject to a lot of things (maybe even including moon phase! who knows). Joking aside, the fact that it renders "fine" on 22.3 is a pure accident: for example when checking rendering in frame capture you can clearly see that rendering is different from the "normal rendering on device". There are several possible workarounds (maybe not viable in the full project):
1. Second camera can clear depth (this is "free", so no performance impact) - it will make sure that depth is filled with non-NaN values, making depth comparison predictable
2. This is more specific to repro, I would say: you can reorder cameras so that shadows rendering happen in the first camera; then actual rendering for first and second cameras can be shared (but this approach is quite fragile, I must say)
3. You can switch to URP+RenderGraph which would make these decisions (having memoryless render surfaces) with full knowledge of global usage of them

To summarize: memoryless depth backbuffer is well suited for the setup of "one camera renders to backbuffer the final result" since this avoids all these potential pitfalls. Indeed, the fact that camera renders shadows before doing "normal rendering" does not interact well with memoryless depth