This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND Developer forums.

Descriptive Problem Summary:
With the map_format set to SIDE_MAP movable atoms don't seem to slide under stationary big atoms correctly. When standing on the same x coordinate as a big atom, then stepping north, the "draw layer" of the moving atom doesn't finally update until its movement animation has completely finished. It slides over the big atom then finally drops a layer and is drawn behind it.

This behavior seems to be reversed when walking south. The moving atom's layer will instantly pop above the stationary big atom when moving south. I've built a demo to help illustrate what I'm trying to describe here. Notice how the red squares instantly pop over the larger object when walking next to it.

Expected Results:
What should happen is having an atom's draw layer update immediately after moving north rather than after its moving animation has completed. The reverse should be so when moving south, the moving atom should remain at its lower draw layer until fully completing its moving animation.

Until you can fix the downloads for your demo (you must have uploaded them as hidden files), I've been exploring this on my own. I was able to see an issue with a tree icon similar to the one you showed me in your demo, but the only way I could trigger it was if the tree had a lower layer than the mob, such as if it was a turf overlay. I realized in the process that the behavior I was seeing is actually correct. Because the tree has a turf layer, while the mob is partially on that same row (y) it will be drawn above any turfs on that row. As soon as the mob stops on the y+1 row, the tree draws in front of it as it should.

I seem to recall there was more to your demo than that (besides the shadow thing you resolved with EFFECTS_LAYER), so it'll be worth looking at that to compare the results. If the tree is a single icon and it's on a turf layer then the mob should draw on top of it when it's between the y and y+1 rows, or on the y row, but never any other time.

Other people are reporting the files are downloadable, must have been a temporary hiccup.

As for the EFFECTS_LAYER workaround, it works to a degree but seems to have it's own strange issues. The layer of other objects seem to be effected by your own y coordinate. While north of other atoms they're always drawn under anything on the EFFECTS_LAYER. If you're south of the same atoms they're drawn above EFFECTS_LAYER. Big atoms are always drawn above it, mobile atoms are drawn above it when they move just like I described in the bug report.

I've also noticed /images being drawn under big atoms even if the images are on EFFECTS_LAYER. It only seems to happen when your y coordinate is below the two.

I confirmed my suspicion on your demo. The trees you added are in OBJ_LAYER. While the mob is straddling between y and y+1, the trees will be underneath the mob just like they are if the mob is only on y, which is correct behavior. Changing the trees' layer to MOB_LAYER+1 eliminates the problem entirely.

Offsetting pixel_y will effectively move an object to a different row. The effective row of an object in SIDE_MAP is y + floor((pixel_y + glide_y) / icon_height).

Your new demo shows the pixel_y being set to -64 (two tiles down) for the east and west directions, and for south it's -160. The north direction puts pixel_y at 32, one tile north of the player, which is therefore one tile further back. All the other directions have a negative pixel_y so they will pull the icon forward from the player. The behavior for every direction, at every level of the trees, is consistent with my predictions.

I did find and fix a separate issue, which shows up slightly in your demo. If you stand 2 tiles east of a tree's base and 5 tiles north, face south, and use the Pew verb, you'll see the yellow square on top of the tree's base; in all other cases of standing at y+5, the icon is below the tree. The yellow square should be below the tree as well, and this is not happening because x position was being taken into account inappropriately.

Not so much, no. The problem is that while gliding between rows, a mob has to appear as if it's on the nearer row in order for things to be drawn in the right order. Gliding is applied to the regular pixel offsets. That may be separable from the regular offsets with some work, but as a practical matter it's not very feasible and it would also interfere with using pixel-based movement.

pixel_z, however, can be adjusted without any change to the row. The value of pixel_z is not foreshortened (though in your demo that's moot, as the tiles are square) and it does not impact the nearness of the atom in any way.