This flow with magic tokens in the path still sketches me out a bit... I know some degree of messiness is unavoidable given our use of fake paths, but I'm wondering if we could clean it up a tad something like this:

1. DocumentManager exposes a createUntitledDocument() API that explicitly sets up the dummy path and non-FileEntry-type doc.file
2. handleFileNew() calls that API to create a document, then immediately calls DocumentManager.setCurrentDocument() (everything else in doOpen() is irrelevant stuff, concerned with file I/O).
3. No need to export nextUntitledDocumentPath() anymore
4. I guess _savePreferences() could continue to use the indexOf() for now... or we could switch to a more verbose but less-hacky approach like looking up the path in _openDocuments[] and checking isUntitled() if found.  I'm ok with either I think.
5. To make the odds of collisions even more remote, can we add a prefix to the random number, e.g. "_bk_untitled\<random\>"?  There are various other apps, logfiles, etc. that use random-numbered names too so there's always a small chance any old path will contain the number we picked.

I like this mainly because it somewhat reduces the degree of ping-ponging dependencies between DCH & DM, and makes the creation of this special type of doc a little more explicit...  And it makes the File > New flow a little easier to follow (no need to read past lots of file I/O code in both modules, trying to picture how/if it all gets short-circuited out).