message-add-action problem

[Karl Kleinpaste <karl@charcoal.com>]

No Gnus v0.3, XEmacs 21.5.20.

For a very long time, I've been doing message composition in a separate
frame, using code I got from someone (unremembered, regrets) on this list:

  ; destroy the composition frame on any kind of exit from composition.
  (defun delete-frame-unless-tty ()
         (if (equal (console-type) 'x)
           (delete-frame)))
  (message-add-action 'delete-frame-unless-tty 'exit 'postpone 'kill)

  ; function to express "separate frame for composition startup".
  ; this is used conditionally on being in an X frame already.
  (setq gnus-karl-message-configuration
	'(frame 1.0
		(if (not (buffer-live-p gnus-summary-buffer))
		    (car (cdr (assoc 'group gnus-buffer-configuration)))
		  (car (cdr (assoc 'article gnus-buffer-configuration))))
		(vertical ((user-position . t)
			   (top . 4) (left . -1)
			   (name . "Message")) (message 1.0 point))))

  (gnus-add-configuration (list 'message gnus-karl-message-configuration))
  ; plus several similar -add-configs, for 'reply and whatnot.

However, since I upgraded to No v0.3, my message composition frames
are not deleted on send/kill/postpone any more.

message-mode's define-derived-mode in message.el is destroying the
global value of message-*-actions by making them all locals and
aggressively setting them to nil.  This can't possibly be correct,
unless these variables were never meant to be user-accessible.  That
was not my understanding.

When I tweak message-mode to re-assert those variables' values in the
make-local, the basic idea seems to come back...except that it's my
main Gnus frame that gets deleted, leaving the composition frame,
exactly the wrong effect.  (But that frame now shows *Summary*.)

A side issue is that, with some regularity but no consistency I have
yet identified, when I start composition, sometimes the newly-created
frame gets used by Gnus for the original pile of normal Gnus buffers
and the original frame is taken over for the message buffer all
alone...again, exactly the wrong effect.

I've tried to crawl through the text in info://Gnus/Window+Layout but
frankly the wording is so convoluted that I simply don't follow it.  I
tried adding a "frame-focus" element to the specification shown above,
next to "point", but it didn't seem to have any effect at all.

Can anyone offer thoughts on [a] why the message-*-actions are being
canceled by message-mode in the first place, [b] how to reliably get
their global values in use again, [c] why Gnus is deleting exactly the
wrong frame, and [d] why the new frame is sometimes misused as the
general Gnus buffer set instead of just for message composition?

--karl