Here, I need to retrieve the MyComponentMediator associated to the MyComponent parent (and only this one!)in order to alter its state....here is my problem!
You don't need to retrieve the MyComponentMediator, you just need to send a notification it is interested in. Yes, both instances of MyComponentMediator will respond to the note, so you pass something in the type property of the notification that will allow the two instances of MyComponentMediator to discriminate and only act on notes meant for the right instance. This could be a bit of information shared between MyComponent and MySubComponent, for example. MyComponentMediator could look at the type property and if it is equal to some property on its view component, then it acts on the note.
Here is my question to you: is there a good reason for you to build this big mediation loop? Why doesn't MyComponent listen to MySubComponent for the same event, and change its state in the handler? Why go the long way around the barn?
Now there may be a perfectly good reason. Perhaps once the Mediator is in receipt of the event, it needs to collaborate with a Command to perform some business logic or maybe it needs to fetch some data from a Proxy and pass it back to the view component. If this is the case then consider the above solution and carry on.
But if the whole loop out through mediator-land is just an exercise in trying to apply the framework, then take the shortcut and don't mediate this collaboration. View components should be able to encapsulate their own behavior for the most part and tying a simple state change to a button press certainly falls within that realm. Only when an interaction leads to some business logic interpretation, model change, or distant and awkward to achieve view component change does mediation really make sense.
-=Cliff>