The package enables itself on load (second to last line). 
That's
 against XEmacs policy and _must_ be deleted before distribution. 
Changed and documented.
What about requiring the same from `viper', which currently may
viperize on loading when certain variable is set?
 The new variable `auto-coding-alist'
 partially duplicates the functionality of `file-coding-system-alist', 
Added a new documentation chapter describing how package interferes
with core XEmacs.  Agree that `auto-coding-alist' duplicates core
functionality.  It was left there to facilitate updating from new
Emacs version.  Perhaps should be deleted entirely (with documenting
it in comment).
 normal package policy of
 choosing a prefix and using it consistently 
Doing nothing to naming inside package.  The reason is the same:
facilitating updating from Emacs.
 There is GNU-only functionality (buffer-is-unibyte) referenced; the
 package should be marked "experimental" until 
I don't see `buffer-is-unibyte' in package elisp code.  What sort of
reference do you mean?  What field in package mark it as
"experimental"?  I don't see such a word in package system
documentation.
 Otherwise, if convenient, perhaps the best way to handle this is to
 create the new package but not release it until revised, and then the
 author can work directly on it in CVS. 
If somebody is going to create new CVS module for the package: I am
already registered as CVS committer, needing only permission to write
into that module.
With all this, here is new package version.