>    Then the problem is with the following stretch of code in
 >    `fill-paragraph':
 >
 > 	  (and fill-paragraph-handle-comment
 > 	      ;; Our code only handles \n-terminated comments right now.
 > 	      comment-start (equal comment-end "")
 > 	      (let ((fill-paragraph-handle-comment nil))
 > 		(fill-comment-paragraph arg)))
 >
 >    We have to find something more intelligent here.
 >
 > Is this really the place?  If I add a call to error just before the
 > fill-comment-paragraph call, none of the four bugs cause it to be
 > called.

Correct.  But what I wanted to express was that `fill-comment-paragraph'
will get it wrong for a block comment.  The following part is used to
find the end of the region to fill by searching for `comment-re' at the
begin of every line which fails for block comments.

	     ;; Find the beginning of the first line past the region to fill.
	     (save-excursion
	       (while (progn (forward-line 1)
			     (looking-at comment-re)))

 >    It might be better to recognize Lisp "#|...|#" comments explicitly at
 > a point where we know we're dealing with Lisp.  The attached patch is a
 > total hack, but it seems to relieve the symptoms of the first three bugs
 > (and changes that of the fourth).  This style of comment can be nested,
 > so the hack will get confused if still inside a comment but after an
 > inner comment.  The changed symptoms of the fourth bug suggest that the
 > bounds passed to the fill-region-as-paragraph call are wrong.  But I'll
 > bet someone else can do better.

I'm afraid this problem is not restricted to the Lisp case.  I think we
should modify `fill-comment-paragraph' to

(1) check whether the current major mode allows comments that are not
terminated by a newline,

(2) if (1) applies parse whether we are in such a comment or a nested
comment, and

(3) call `fill-comment-paragraph' iff (2) doesn't apply.

Anyway please try the attached patch.  I'm confident Stefan will find
a better solution soon.