Scratch

The ordering of layers in scratch is a rather awkward interface, as the only thing you can do is move to the front, then move back n layers.  This means that the order in which you execute the scripts for the sprites matters, requiring a lot of extra trouble to get things to work.  (If scratch had adopted a 2.5D model, with a Z-depth for each sprite, the code would be much simpler.

For now, the simplest way I can think of off the top of my head is to have only ONE sprite respond to the key (the backmost one), have it move to the front then send a message to the next sprite, which moves to the front and sends a message to the next sprite, and so on.

This is *much* messier than having  "set depth to ___" in each sprite, but is necessitated by the "deck of cards" model that scratch uses instead of a clean z-axis model.

The difficulty with "layers", as Kevin points out, is that they aren't really specific.  For instance, if you had 4 sprites that together made up a layered figure, there isn't an easy way to order them, because:

If each sprite has "Go to Front" in its script, and all of them start when a certain key is pressed, the LAST one to go to the Front defines what the front is.  You're likely to get something different each time.  Instructing the sprite to go back a layer (or more) doesn't mean much, because you don't know what layer it's on...

I struggled with this and came up with a solution of having the sprites "wait" by different amounts of time before "going to front".  So each script (when the green flag is pressed) starts out like this:

Bottom Sprite:
(Green Flag)
(Go to Front)

Next Sprite:
(Green Flag)
(Wait 0.1)
(Go to Front)

Third Sprite:
(Green Flag)
(Wait 0.2)
(Go to Front)

And so on.  The last Sprite, which waits the longest, ends up in front.  This is clunky, but works OK.  Kevin is thinking of something more sophisticated, but my solution may do what you're after in this case.