Just in case anyone views this question in the future, I found the 'official' answer.
In MGM (and Passive View), the model is supposed to contain all necessary state information. So in this case the application model would keep track of which is the focused control.
In the example of a multi-document editor, you'd have an application model that handles the various menu commands and keeps track of which editor currently has focus. It's easy then to delegate work to the editor model corresponding to the focused editor.
(This isn't actually the solution I adopted. The state information was already contained in the GUI and I didn't want to duplicate this in the model - it always seems clumsy keeping the same information in more than one place and has the highly undesirable potential for introducing inconsistencies. This is perhaps one weakness of patterns such as MGM and Passive View. Anyway, I went with the 'hacky' workaround I described in the question.)
Just as a footnote, another way to handle this kind of situation – where the control handles a lot of functionality and state that you don't want to duplicate in the model but to which the model needs access – is to define events in the model that it can call when it needs to access said functionality/state. Using events keeps mediator dependencies out of the model, which is a basic requirement and raison-d'etre for MGM.
For example, if a control has the ability to save its content, define an OnSave event in the model and have the mediator hook up a handler that invokes the save functionality in the control. The model's Save method then just calls the event, and the control takes care of the implementation without the model having to know anything about it.