>>> Your current code makes it impossible for a major mode to make Emacs 
>>> slow by widening in a too-long-line.
>>
>> Which is a good thing, isn't it?
>
> No: we don't want to prevent people from shooting themselves in the 
> foot. Basically if it says "impossible" there's a good chance it's not a 
> good thing.
>

Apparently you don't understand what I'm doing.  I'm trying to make Emacs 
handle exceptional cases gracefully, by:

1. adding as few hard limits as possible, and

2. keeping as many functionalities as possible (my task would have been _a 
lot_ easier if I had just stopped after saying "just open these files with 
M-x find-file-literally").

If you think there's anything wrong with that approach, I'll have to 
conclude that we live on different planets.  On Earth and on Theory, 
maybe?

And no, it's not even "impossible" for Emacs uses to shoot themselves in 
the foot, so your argument collapses.  Those who prefer the "Traditional 
Emacs Approach"™ when it encounters such exceptional cases, that is, 
those who:

1. do not want to add any limits whatsoever in any circumstance, and

2. agree to take the risk of making Emacs completely unfonctional,

can simply add (setq long-line-threshold nil) in their init file.

>> I just sent one such example to Dmitry.  And I pointed to another 
>> possible solution, namely to scan the whole buffer while opening it 
>> (instead of scanning it lazily, which is IIUC what currently happens). 
>> From a user viewpoint, it's understandable that opening a big file 
>> takes some time.
>
> We used to scan eagerly in the background with `jit-lock-stealth`, but 
> that was not very popular (eats up your battery for fairly little 
> benefit). We also have "lazier" highlighting via `jit-lock-defer`, but 
> that hasn't been adapted to `syntax-ppss`.  It might be worth 
> investigating.
>

It might be, indeed.  But I will most probably not do that myself.