Moving it to xemacs-beta.  Concerning what is matched against charset
registry while instancing font in X.
 > the entire font name, on X devices
 it only matches the registry field as defined in the
 XLFD standard. 
 I don't understand what you mean here. 
No kidding.  It is actual behavior [1].  If this is intolerable, then
`x_find_charset_font' itself needs patch, so that we can remove X
reservation from font instancing documentation.
Footnotes: 
[1] My xemacs does call sequences like this.  (Will send more gdb
backtraces on request.)
fast_string_match (regexp=1081165372, 
    nonreloc=0xbfffd730
"-b&h-lucidatypewriter-medium-r-normal-sans-12-120-75-75-m-70-iso8859-1",
    reloc=1080332560, offset=0, length=-1, case_fold_search=1, 
    errb=
      {really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 666},
no_quit=0) at xemacs-21.5/src/search.c:533
x_font_spec_matches_charset (d=0x8582710, charset=1081689636,
    nonreloc=0xbfffd730
"-b&h-lucidatypewriter-medium-r-normal-sans-12-120-75-75-m-70-iso8859-1",
    reloc=Qnil, offset=0, length=-1, stage=0)
    at xemacs-21.5/src/objects-x.c:965
x_find_charset_font (device=139994896, font=141607140, 
    charset=1081689636, stage=0)
    at xemacs-21.5/src/objects-x.c:933
font_instantiate (specifier=1081807280, matchspec=148726376, 
    domain=141312384, instantiator=141607140, depth=3)
    at xemacs-21.5/src/objects.c:863
A *generic* matching function (knowing nothing about X) is really
applied to entire font name.
Perhaps that is why `x_find_charset_font' contains comment:
  /* #### This code seems awfully bogus -- mrb */