>> Yes, occasional mis-fontification is expected.  It's a compromise 
>> between "no fontification" and "slow fontification".
>
> I wonder now if the majority of the slowdown was caused by the 
> redisplay, whereas font-lock (which only has to run once per screenful) 
> was actually "fast enough".
>

Those two statements are not mutually exclusive.  The majority of the 
slowdown was indeed caused by redisplay, but font-lock was not fast 
enough.  Try to open a sufficiently large file (e.g. the dictionary.json 
one) with the code on master, and type M->.  You'll see that Emacs needs 
about five seconds (on my laptop) to display the end of the buffer.  Now 
compare that with the feature branch, with which the end of the buffer is 
displayed instantaneously.  That five seconds delay is caused by 
fontification-functions.

>
> Could you clarify what you mean by "access ... to the place where ... is 
> defined"? "new Downloadify.Container" is highlighted by a regular regexp 
> matcher, not some custom elisp code which has to visit the position 
> where the identifier is defined.
>

Sorry, I cannot be more precise, I don't have the "downloadify.js" file 
here.  It was just a guess, based on what I saw on the screenshot, that 
one function called by fontification-functions collects all class 
definitions and highlights their identifiers elsewhere in the buffer with 
a specific face.  When the buffer is narrowed, that function may not see 
the Downloadify.Container definition (which is, I guess, placed near the 
beginning of the file) anymore.