Hrm...I don't think you thought about this in details...or checked the code of the latest version.
I'm already using walk sprites (basically, it's the bottom third of my main sprite) for collision with the collision layer. And collision layer objects also need to feature parts of objects in the foreground layer that are meant to be colliding, them too representing the bottom of those objects (like with the fence). As I already said (not sure if here), foreground layer represents those objects that are in level with the player (the player can be in front and behind them) and they are pasted over the base layer.
For the player to be able to appear behind and in front of them I need to loop through the foreground objects twice, once before the player pasting and once after. I don't how this can be solved without some sorting, but it's pretty much the same.
In the currently scheme it's - check for foreground sprites above the player and paste them, paste the player, check for foreground sprites below the player and paste them. With sorting it would prolly be, sort foreground sprites according to player's position, paste the first group, paste the player, paste the second group of sorted foreground sprites. The second doesn't sound better.
The only way to avoid collision layer definition I can think of is foreground tiles pointing to colliding tiles in the tileset, so I wouldn't have to manually define the collision layer. This, on the other hand, would mean forcing a certain tile arrangement format to the user (like the appropriate collision sprite following the foreground sprite in the tileset).
