Alright, now I'm having a clearer picture of what you actually want. In the opening post you only spoke of "objects interacting with one another", so naturally, I assumed you meant game objects in a game world.
You've mentioned a state stack. I think these are used at least somewhat commonly in games (have seen it being used in at least one major title I worked on). However, in your sample picture, you show a structure that looks more like a tree than a stack. How comes? In an actual state stack, states would be layered directly on one another and you would only have a single top-most state at all times. Stacks are usually pretty simple in structure, unlike trees, so maybe that could be a hint that you are trying to overcomplicate the solution.
Also you mentioned that you want arbitrary objects in the stack to be able to communicate with one another. Why is that? It's a bit difficult to comprehend. For example, let's say you had a "main menu" state, then above that an "in-game gameplay" state and on top of that a "pause menu" state. You're saying you want the "pause menu" state to be able to communicate with the "main menu" state, for example? Why is that? I don't see a clear benefit, and it seems like a dangerously over-flexible system that could easily lead to problems when not handled super carefully. I'd say in a typical state stack, state objects should only ever be able to directly communicate with their immediate parent, so getting a message from a hypothetical object C to a hypothetical object A would require passing the message throubh object B first.
While I currently don't quite understand how you plan to utilize a flexible system like this, if you do have a need for it, what you're probably looking for is called an "event handler". Basically, there should be some global object receiving and handling events. Every single one of your state objects could send events to this handler. Then each frame, this event handler would go through its list of events and traverse the state stack, passing them to every single state along the way, until either a single one responds to it or it has run through all states.
For example, object C could send an event "Event_IJustDidSomethingCool", and then during event handling, object A (among others) would get the event "object C just sent Event_IJustDidSomethingCool". It could then either ignore the event or decide "WOW, this is super relevant to me, I should probably do something!". This "something" could be whatever you need. The state could just manage some internal stuff, but it could also go on to send an event of its own (like a response to object C, for example). Anyways, it should end with object A communicating to the event handler "Thanks, I handled this event", which should make the event handler clear the event from its queue, no longer sending it to any other states.
That's a very typical event system, and in games, something like this is very commonly used for UI, especially for input handling. Though in that case, it's not really multiple UI objects communicating with one another, but rather an extern input handler getting the player's input and then sending events to all UI objects until a single one decides to respond. This also answers your question on what happens if a state object doesn't actually exist in the stack: nothing at all. The event is simply sent to all existing state objects and ignored by all of them, causing nothing to happen at all.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!