There might be a case for the multicaster returning a Visitor of its own (the Traveller). The Traveller could encapsulate, at its simplest, the act of returning/removing the original Visitor. A more complex version could allow the caller to replace the contributed Visitor with a different one. This has several advantages: because the Object only has to pass through the Traveller, a single 'addListener()' type method is now sufficient for most functionality. Secondly, the Traveller safely exposes the client to powerful functionality (replacing the contributed listener, cancelling the listener, etc.), as it grants this access per visitor, and not by multicaster. In some cases, the client may not even need retain a reference to the listener any more.
~
A thought: The Visitor Pattern's match.