> Here's a tentative fix for the bug, not that well tested, but tested a
 > little bit:
 >
 > 2006-12-04  Alan Mackenzie  <acm@muc.de>
 >
 >     * emacs-lisp/lisp.el (beginning-of-defun-raw): In the seeking a
 >     non-nested open-paren case, check there are enough lists to move
 >     over.  Return the correct value.

Thanks for taking care of this.  Please note:

1. You don't widen the buffer before calling `syntax-ppss'.

2. A construct built along

(foo
) (bar)

with point at "bar" might derail font-lock (remember,
`c-beginning-of-defun-1' calls `beginning-of-defun', not
`beginning-of-defun-raw').

3. All this is still awfully slow and expensive: Open a larger buffer
like xdisp.c, jump to its end, hit M-v a couple of times, and look at
CPU consumption.

4. You could avoid the tedious `up-list' steps by using a variant of the
tentative fix I attached.

5. Consider making `open-paren-in-column-0-is-defun-start' a real user
option in C mode.  Let, for example, users decide whether they want to
respect GNU coding standards as mentioned in

http://lists.gnu.org/archive/html/bug-gnu-emacs/2006-11/msg00037.html

This should also permit binding C-M-a / C-M-e to `c-beginning-of-defun'
/ `c-end-of-defun' when `open-paren-in-column-0-is-defun-start' is nil.

6. In any case, the new behavior should be documented since it applies
whenever `open-paren-in-column-0-is-defun-start' is set to nil.