Strange interaction between three seemingly unrelated components

[Geoff Gole]

Various parts of my .emacs evaluate some seemingly unrelated bits of
code that behave strangely when evaluated in a certain order. The
minimal example seems to be:

  emacs -Q
  (progn
    (require 'bytecomp)

    (defadvice blink-matching-open (around enable-blink-paren-hack activate)
      (let (show-paren-mode) ad-do-it))

    (custom-set-variables
     '(uniquify-buffer-name-style (quote post-forward-angle-brackets)
nil (uniquify)))

    (defadvice blink-matching-open (around enable-blink-paren-hack activate)
      (let (show-paren-mode) ad-do-it)))

This sequence corresponds to loading .emacs at startup, making a small
unrelated change, then loading it again. After the code has run
blink-matching-open is thoroughly broken, recursing infinitely if
invoked (such as by typing a close paren). Both the order of the code
and the contents of the custom-set-variables form seem to be necessary
for that to occur.

I don't understand this at all. Why would (require 'bytecomp),
defadvice and custom-set-variables interact in this way? How might I
debug this bizarre problem?

*Messages* tells me:

ad-handle-definition: `blink-matching-open' got redefined
blink-matching-open
ad-Orig-blink-matching-open: Lisp nesting exceeds `max-lisp-eval-depth'

A partial backtrace:

Debugger entered--Lisp error: (error "Lisp nesting exceeds
`max-lisp-eval-depth'")
  ad-Orig-blink-matching-open()
  ad-Orig-blink-matching-open()
  ad-Orig-blink-matching-open()
  etc

Version:
GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of
2008-11-22 on elegiac, modified by Debian