>> That's what I initially thought, too.  Now I tend to think that it 
>> would be better to not decouple these two cases, because it would be 
>> too expensive to distinguish the four possible cases, namely:
>
> I'm fairly sure that my branch demonstrates that there's nothing 
> expensive about it.
>

If you think this, it means you do not fully understand the problem, 
sorry.  Detecting the presence of long lines in a buffer takes time, and 
it takes more time as the buffer becomes larger.  Again all this has been 
discussed, tested and fine-tuned a month ago.

>
> It's just one commit, 20 additions, 10 deletions. It should take 2 
> minutes max to read and understand it.
>

As I said, I tested that commit.  And I understood it, too.  What you do 
there does not even depend on the presence of long lines in the buffer (or 
on the length of the buffer).  Moreover it does not offer any protection 
against modes which use widen in their font locking routines.  Which was 
the main reason to add the locked narrowing feature.