I've read a few suggestions for pen layers over the last few years and I've wondered to myself, “this would be very useful, but isn't it too complicated?” Sprite layers are already convoluted to deal with for new users, and another set of layers that interweaves the existing set sounds like a bad idea.

After some thinking, I realized the biggest (only?) use case for pen layers is dynamic sprite rendering, i.e. when a sprite isn't just a set of fixed graphics but something whose display needs to be dynamic, like a HP bar or a line between two sprites. There's a simpler way to support this use case.

erase all on [stage v] layer :: pen
erase all on [sprite v] layer :: pen

bring pen to [stage v] layer :: pen
bring pen to [sprite v] layer :: pen

The stage pen layer remains the same - pen draws on top of the stage, beneath everything else, and that layer is shared with all other sprites. The sprite pen layer is localized and always rendered on top of the sprite doing the drawing, although it does not move with the sprite. Mouse events would fire on the local pen layers as if they were part of the sprite.

This feature offers a lot of bang for its buck compared to other ‘pen layer’ suggestions. It's less immediately obvious what the blocks do, but pen projects become much less complicated to set up. No more broadcasting every sprite to render in the reverse of actual sprite order, nor doing geometry & communication to figure out when the mouse clicks a sprite, you can just program pen projects exactly the same way as you program regular projects as well as interweave pen-based sprites with normal sprites.

+1
seems like something I'll use.

when (::ff0000) horribly misclicked and pressed @greenFlag instead.:: hat :: events 
Summon Evil Kumquats using (((((((((((((:D):: motion):: motion):: motion):: motion):: motion):: motion):: motion):: motion):: motion):: motion):: motion :: motion)

Semi-support. This.. is useful but adds a little more complications to pen.