It looks like it's not sorting the depth according to the camera view but is doing it according to the sprite order in the scn as one wall is perfectly fine while 2 have the error.
The elements in a scene are rendered as if
1) each is drawn on its own layer of transparent film
2) these layers are then stacked in the order in which they appear in the .scn file
the first step takes the distance from the camera into account. The second does not, If you don't account for this in a.scn file the results can, and often do, look very odd - especially if you are moving things about in a scene by animating their positions or they are rotated about X or Y. If complex movement is involved then it is often necessary to duplicate elements and animate their opacities such that only the right one is visible at any time.
As an aside, I think the GLSL fragment shader language provides a way to change the Z buffer value of a pixel which could form the basis of correcting the ordering so that it is based on position in 3D space, but I have not investigated it yet. It is on a long list of things I hope look at.
The finish of this really surprises me every day (I never imagined that the software will endure something so complex). Visually playing with perspectives and other gadgets, it makes the software very entertaining and with good hardware it is really a delight.
I also find it surprising just what can be accomplished using just the functionality provided by the .scn files even without resorting to either fragment shaders (the .fsh fils) or vertex shaders (there are a few scenes around that use these to distort the geometry).
I first got hooked by scenes when I created my "experiments with carousels" which I treated a kind of puzzle to see how far I could push the capabilities of the .scn files - then I discovered the fun of shaders.
However, it has to be admitted that doing anything complicated involves a lot of often very tedious work. I have quite a few ideas that could lessen that - for example the use of macros I mentioned a few posts back, some built in arithmetic capability and the ability to direcly specify the sorting order for sprites rather than having it simply be the order in which they are defined. One day I may get those ideas into a coherent form and post them here.