HyperPad may see this as an intent of the object itself since the object is in the tag's group. Similiarly to using the loop behaviors to iliterate each object, it does it to only one object at a time.
In this case, the collision behavior will activate the following events because of each object that is collided within it's tag, it will have the intent of that object that it has collided to.
For example, two objects are going to be used. Object 2 is in a group. Object 1 has a behavior where when it collides within that group to change the color of it's tag. If object 1 collided with object 2 with the tag, it will change the color of object 2 as object 2 was the intent of this case.
This may be confusing, but I learned from experimenting with tags and looping properties.
If you want to respect the original objects layer then don’t use spawn on object, instead use spawn.
this also disrespects the original layer of the spawned object.
Common sense AND convention of spawning's uses in all other environments trump your anecdotal experiences with a dozen users and naive newbs, regardless of the timeframe. Particularly because they're going to move on from your app to the rest of the world's creative products, most of which use the following conventions.
Spawn AT (doesn't exist in hyperPad, is a specific point. Requires user fudging in hyperPad)
Spawn [with]IN (geometric space inside a shape, and what you call Spawn On)
Spawn [up]ON (geometric space along the edges of a shape. Doesn't exist in hyperPad)
None of these alter hierarchical structure, they always respect the editor layering (by user) where it's available. Layering, sorting and other hierarchical choices of a user are always presumed deliberate and therefore respected. Layering is a completely different type of sorting, in a different place, for different reasons, none of which pertain to geometric space, except Z-sorting in 2D, in which case the layer sorting becomes imperative to the user, and should be respected by the engine for this reason, alone.
That should be reason enough to consider respecting layering choices of an end user. But I see it's not. So let me make other cases:
Your app is a gateway drug to the worlds of digital creativity. If you want to be fondly remembered, referenced, revered and referred to, your best bet is to match your tooling, paradigms and processes to where your best (and most influential) users will eventually find themselves. Then those 6 years of users experiencing your product might actually mean something to others, and help create exponential user growth.
Most obviously and logically important, when layering matters most (performance optimisation), the processes of manually moving newly spawned objects between layers will further hurt already tight performance constraints the user is deliberately using layers to attempt optimising around. So your current approach confounds the very best possible use of layers.
I apologise if my making of more than one point is confusing, or bewildering. Also, sorry if my appeals to logic, rationality and reason distort your constrained perspective.