Achievement unlocked:

We're not turning a blind eye to the core problem. But coming up with an elegant (and feasible) solution takes some time. While not perfect, we update things like the message system as a work around until a proper solution is in place.

Unfortunately given the nature of "visual programming" you usually need to work around things to make it work the same way as traditional programming.

Please don't consider the problem, think about the question I'm asking from the perspective of: What are the capabilities of awareness and messaging within spawned objects?

@Jack8680 I think this approach sounds somewhat similar to how prototypes work in JavaScript.

In hyperCard: I'm still struggling with how an object can have awareness of itself and use that knowledge to pass some information of itself to something else.

In plain speak:

Spawn a bunch of bumpers for a pinball game:

When one is hit by the ball it sends a message describing the collision (from whence the ball came, at what speed and where it got hit) to a scoring system, along with information about itself, like its position and current points value and the time of the contact and other state it might have been in at the time of the contact.

For this, example couldn't you just use broadcast message and send all the relevant information? The main hurdle, would be that you need other behaviours to first get the position then put that into broadcast.
Attributes work as well. This was one of the reasons why we built attributes. You can give your object certain properties. (like points). Then any other object can see that objects attributes. The attributes method doesn't work so well in the case of spawned objects. But I think the new broadcast/receive messages should.

In hyperCard: I'm still struggling with how an object can have awareness of itself and use that knowledge to pass some information of itself to something else.

In plain speak:

Spawn a bunch of bumpers for a pinball game:

When one is hit by the ball it sends a message describing the collision (from whence the ball came, at what speed and where it got hit) to a scoring system, along with information about itself, like its position and current points value and the time of the contact and other state it might have been in at the time of the contact.

Before OOP

Teach a man to fish... etc

Too subtle for you?

If you have a game with objects you want to select by position, their IDs could be based on the X and Y position.

If you want to be able to select the Nth spawned object or just give an object a unique ID, create an attribute on some non-spawned object that always exists, and let the spawned object get this value, set it as its ID, and increment the value by 1.

You can use this kind of thing to add a relationship between objects. If you want a long and probably hard to follow example I'm making a game right now where an enemy spawns a hitbox for a sword thrust, that will damage the player, unless the player is parrying, which will deflect the hit and stun the opponent for a moment.

Enemies spawn a hitbox are spawned using a broadcast message, broadcasting to 'damageBox' with the value being an array of information (owner position, rotation, offset to spawn at, etc).

I have an empty object that is never destroyed that receives this message. When the message is received, it uses an internal object counter in the form of a box container, which is incremented by 1 each time. It combines this with text to make a unique attribute for each hitbox being spawned. It sets this attribute to the array of values.

The hitbox object is simply an empty object that uses the values passed on to it to calculate the position and rotation it should go to. It uses an incremental ID attribute on the main empty object to get the attribute that was set before (a work around because when multiple run at once there is a slight delay before spawned objects run, so they would all get the last attribute without an ID system). The Hitboxes set an attribute to the ID of their owner.

The player has behaviours when collided with the hitbox, if the player is parrying it will get the hitbox' owner attribute and broadcast to combine text of "parry" and the owner ID. The owner has a receive message for this that causes it to turn of its behaviours for a moment.

Spawned objects are basically exact replicas of the object. They can, for the most part, work independently with the exception of not being able to be talked to by object name. Although you can use tags for limited use, for example put a tag on the object and then it or any of its spawned objects could have a collide behavior with that tag, and then when one collides only that one would react.