I noticed in games where a "character" is made of more than one (ags) character, it needs some sort of "grouping". In Dave's (and I think Francisco's too) games, there's this issue a "character" may pass in front of another but the head of the "character" that is behind is instead in front, this usually happens by the chance when the 4 (head+body char1 and head+body char2) are all in the same baseline.

By being predictable at least if the scenes are tested and some way is found for this not happen when it does at least there's an expectation that using different compilers/ports won't change the tested behavior.

I found that 3.6.1 introduced a problem related to object sort, after optimizing Overlays storage, which I did not realize earlier.

Previously the overlays were constantly pushed into the vector, so newer overlays had always higher container indexes. After optimizing this storage for speed (#2048) the internal container index is no longer related to the order of creation.
This, simply put, breaks overlays sorting on screen in the old games, where they did not have ZOrder property.

EDIT: to think of this, maybe this was potentially broken earlier, when overlays got sorted among guis, because previously they were not z-sorted at all and just pushed to a render list according to their internal storage order.

In the past there were likely not many games with multiple overlapping overlays on screen, maybe that's why this has not been noticed. I noticed this by pure luck, because of my TypedText Demo game where I create 2 overlays on top of each other instead of merging them into 1 image:
https://github.com/ivan-mogilko/ags-script-modules/tree/master/demos/TypedTextDemo

It looks like I will have to add some solution for overlays at least, which would keep their sort in the order of creation.

UPDATE:
done as experimental commit 278dbc4

An update: today I got reminded of this problem, and after thinking over the code, realized that it's actually trivial to get rid of the special rules for sorting the room objects. These rules existed only for walk-behinds, where they always have less priority (in case of equal baseline). So it's possible to pass a minimal possible value as their "tag" instead of using this hack:
4b522b2
UPD: also pushed to release-3.6.1 branch, because

• looks safe enough; affects only character-walkbehind interaction
• fixes sorting of room overlays among themselves

What remains for this task is to figure out a good rule for defining this "id" tags for objects and characters, and this problem will get resolved.

Different types of game objects do not share same ID sequence. There may be Character with ID 10 and RoomObject with ID 10, and some walk-behind with ID 10. So either their IDs have to be converted to a merged ID sequence of a bigger scale somehow for this sorting, or third parameter used (an arbitrary object type index).

Thinking about this made me realize I missed a good option here.
There's an idea that I had for a while, but could not find spare time to work on:
#969 (comment)
where there will be a "Drawables" interface, and each runtime object will receive its "drawable" id.

Even without a fully implemented system like that, we may have a global "drawable" id still. This id then may be used in this sorting algorithm, in order to achieve a persistent sorting.
There's a "creation id" assigned to overlays now, it may be replaced with this "drawable id", which will have similar result in effect.
Static objects may receive it at the game load / room load. Given there's a fixed "max amount" of room objects currenly, there may be a always fixed range of drawable ids in low numbers. Any dynamically created object will receive ids above that range.