>>>>> Katsumi Yamaoka wrote:
> system (I didn't know it!), which defaults to something according
> to the locale name.
> In XEmacs 21.5, binding of `file-name-coding-system' to nil changes
> `file-name' even if `file-name-coding-system' is nil from the outset.

[...]

> Moreover, binding of `file-name-coding-system' to any coding system
> seems to be a trigger to make the `file-name' coding sysem binary.

I realized there is no difference in XEmacs 21.4.  What I tried
is attached below.

BTW, does this workaround do the trick?

(if (featurep 'xemacs)
    (if (featurep 'file-coding)
	(setq file-name-coding-system
	      (or file-name-coding-system
		  (coding-system-name 'file-name)))))

;; `(if (featurep 'xemacs) ...)' is a compiler directive for
;; letting GNU Emacs generate no byte code.

After performing it, XEmacs at least in Linux box seems to
run with no problem as follows:

--8<---------------cut here---------------start------------->8---
(get-coding-system 'file-name)
 => #<coding-system utf-8 unicode(utf-8)>

(let ((file-name-coding-system nil)))
 => nil

(get-coding-system 'file-name)
 => #<coding-system utf-8 unicode(utf-8)>

(let ((file-name-coding-system 'iso-2022-jp))
  (get-coding-system 'file-name))
 => #<coding-system iso-2022-jp iso2022(g0=ascii, g1=nil, ...

(get-coding-system 'file-name)
 => #<coding-system utf-8 unicode(utf-8)>
--8<---------------cut here---------------end--------------->8---

If it's ok in OS X, I wish XEmacs itself to do something similar.
But it might be necessary to be in `gnus-xmas-redefine' in
gnus-xmas.el (nnmail.el loads it) for those who use old XEmacs.
For the latter case, it has to be guaranteed that the workaround
does no harm even in the distant future.

Regards,