There's also the question of how things like the file tree and commands like Rename find out what the "real" currently selected file is, in light of the usual Editor/DocumentManager APIs all returning null.  I can think of two ways to do that, not sure which is best:

a) Replace your DocumentManager.clearCurrentDocument() with something like DocumentManager.setNonTextDocument(), which would both null out currentDocument as well as store the path of the non-text thing.  Then offer an API like DocumentManager.getCurrentFileAlways() (terrible name, open to suggestions there) that lets people get at that state.  \[This is the closest parallel to the existing model where most code uses DocumentManager.getCurrentDocument()\].

or:

b) In the new EditorManager API, in addition to a DOM node for the UI also pass in the file that this custom viewer corresponds to.  Then offer an API like EditorManager.getCurrentlyViewedFile() to get at it.  You'd still need the DocumentManager.clearCurrentDocument() side channel in this case.  \[This might be a better match to where we want to go in the future, where DocumentManager doesn't own the notion of "current file/document" anymore\].