>
> I see that manually evaluating `(setq-local long-line-threshold nil)' in 
> a buffer where the optimization is already in effect (i.e. where 
> `(long-line-optimizations-p)' evaluates to t) doesn't disable the 
> optimization. Do you have a solution for that?
>

No, and that will not be supported.

>
> Depending on the mode being activated before Emacs decides to enable the 
> optimization (e.g. because one of the first lines is very long, I don't 
> know how exactly this is determined) seems very shaky.
>

Indeed.  As I told you the proper fix is not to disable these 
optimizations, but to adapt the code to handle locked narrowing, by 
explicitly unlocking the locked narrowing when, and only when, it needs to 
access a larger portion of the buffer.

>
> I briefly looked at the branch `feature/improved-narrowed-locking' and 
> saw that locking grew "tags". This probably implies that this is going 
> to be used more in the future, maybe already in Emacs 29.1. Is there 
> going to be some way to disable each and every new tag? Should I monitor 
> Emacs sources for new cases of narrowed locking with a tag previously 
> not used?
>

No, if your function is called inside fontification-functions, you will 
not have to monitor Emacs sources, your code will use a single tag, namely 
'fontification-functions.

>
> What if one day this becomes available to Elisp and a submode that 
> decides to narrow-lock for whatever reason?
>

Don't worry, that won't happen.

>
> Wouldn't something like
> 
> (let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t))
>    (widen)
>    ...
> )
>
> not be much more robust?
>

Definitely not.  It is more important to take measures to ensure that 
Emacs remains responsive for its users than to minimize the effort of 
Elisp programmers.