You've hit the nail on the head. 'Short term and long term' mediators are generally the way it works. Under ordinary practice, I haven't ran into the need for a mediator to 'lose some of its interests', but there are certainly times when a mediator is no longer needed and is removed.
Usually as long as a mediator's view component is alive the same interests exist.
Now that view component may itself choose to ignore data passed to it or to behave differently based on its own encapsulated state, and with Flex States, top level properties might dissappear or reappear depending on its internal state changes. This is in line with the GoF State pattern which says that the component will appear to become a different class.
So in this case, one might argue for dynamic manipulation of mediator interests. But I would always vote for less complexity in the framework. Since the viewComponent has for all intents and purposes become a different class, I argue for a different mediator.
View component VC has States A and B. While in State A, ViewStateAMediator holds the reference to the component. On a VC state change (the mediator is listening for this), ViewStateAMediator unregisters itself and registers ViewStateBMediator passing the reference to the VC. Afterward, it nulls its own reference, and dissapears quietly having passed the torch. Of course ViewStateBMediator mirrors this so that as VC passes between states, it is always tended by the proper mediator.
Its like in school, when its time to learn history, we're tended by the history teacher. When its time to learn math, we're tended by the math teacher. Except on those days when the math teacher is sick and inexplicably the basketball coach is put in charge... Polyester gym shorts and polynomials don't mix folks.