I don't think the documentation or the code needs amendment at all.
Your original issue was this:
If the line observer.notifyObserver( notification ); cause (in the observer) the creation and the registration of a mediator interested in the notification under process, the observer created by the registerMediator() function will be added in observerMap[ notification.getName() ] AND will be precessed in the current for loop because the test expression is observers.length that will dynamically change after the observer registration...
...and you suggested that in order to stop this race condition, the notifiyObserver method should not iterate towards observers.length as it may change if we get loopy and register something that listens for the notification that registered it.
Where exactly is the framework failing to notify previously attached observers?
It always notifies previously attached observers.What you are asserting is that it should not notify observers that weren't previously registered, but were instead created during the act of the current notification. Something that can only happen if you have followed the bad practice of creating a feedback loop.
Logically, when will you
ever need to have a Mediator listen for and respond to the event that creates it? It's like a doctor thinking if only he'd been able to help at his own birth, things would've gone better. He's not interested in his own birth even if he is interested in facilitating the birth of others.
If for some reason, you want to reuse a notification in this way but find yourself battling this race condition, then try using the 'type' parameter of the Notification constructor to disambiguate notifications that should or should not be responded to by a given Mediator. That is, inside handleNotification for the Mediator check to see notification.getType() is set to a value you can logically act on, otherwise ignore the notification and do nothing.
-=Cliff>