Can a 'let' ever lack an 'unlet' in the context of variable watchers?

Can a 'let' ever lack an 'unlet' in the context of variable watchers?

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

Hi,

I've been attempting for a while now to triage why
file-name-handler-alist gets reset to nil on my end sporadically (~once
a day, with potentially hours before I notice).  To that end, I've
attempted to employ a variable watcher.  This variable-watcher grew
increasingly complex as I tried to get as precise of a check as possible
(given that a lot of things change file-name-handler-alist all the time
it was way too over-verbose to try to just log or debug on everything).

Given that this appears to affect global state outside of a lexical
binding (since it persists for a very long time), I figured I should
ignore all changes to file-name-handler-alist that happened during a
'let'.

In an attempt to do this, I started tracking how deep in the 'let'-stack
a given variable change is using code similar to the following:

  (setq arsen--test-depth 0)
  (defun arsen--test (symbol newval operation where)
    (setq arsen--test-depth
          (+ arsen--test-depth
             (pcase operation ('let 1) ('unlet -1) (_ 0)))))
  (add-variable-watcher 'file-name-handler-alist
                        'arsen--test)

(extracted from my full and quite ugly variable watcher)

However, the current value, as I write this message, of
arsen--test-depth is 3.

This only happens when my 'full' variable watcher is in effect AFAICT,
so I suspect that somehow it prevents unlets from being counted (note
that the setq above is the first thing in the 'full' variable watcher
too, so I don't think it can be an error that prevents this code from
running, and debug-on-error caught nothing anyway), but I am unsure
about whether that is the case.

Are there any circumstances in which a 'let' won't have a matching
'unlet'?  Is there a better way to achieve what I am looking for
(detecting variable changes that affect the global/dynamically bound(?)
value of file-name-handler-alist)?

Thank you in advance, have a lovely night :-)

PS: FWIW, but I am unsure about the viability of this, this bug really
seems to act like a let that never got 'undone', especially since I
don't see a reason for anything to be dynamically setting
file-name-handler-alist.
--
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]