The search page was not correctly handling character encoding; specifically, instead of receiving and processing non-ascii characters, it was receiving the UTF-8 octets instead, so search text containing non-ascii characters was not processed correctly, and in fact was returned to the search box as octet sequences.

I puzzled over this for quite a while, first checking all my XQuery and XSLT output code (all correctly specifying UTF-8), then going back to the Cocoon config files. There, in WEB-INF/web.xml, I found this section, where I had neglected to change ISO-8859-1 to UTF-8 (now done, as in the extract below):

    <!--
      Set encoding used by the container. If not set the ISO-8859-1 encoding
      will be assumed.
      Since the servlet specification requires that the ISO-8859-1 encoding
      is used (by default), you should never change this value unless
      you have a buggy servlet container.
    -->
    <init-param>
      <param-name>container-encoding</param-name>
      <param-value>UTF-8</param-value>
    </init-param>

    <!--
      Set form encoding. This will be the character set used to decode request
      parameters. If not set the ISO-8859-1 encoding will be assumed.
    -->
    <init-param>
      <param-name>form-encoding</param-name>
      <param-value>UTF-8</param-value>
    </init-param>

However, this didn't solve the problem. It did cause me to suspect that Tomcat might be the at the root of it, though, so I got Greg involved, and we first checked that Tomcat was being started with the dFile.encoding="UTF-8" flag. It was. Finally, we discovered the problem in the Tomcat conf/server.xml file:

<Connector port="8081" protocol="HTTP/1.1"
               URIEncoding="UTF-8"
               connectionTimeout="20000" 
               redirectPort="8444" />

The attribute URIEncoding was actually missing. Once we added this and restarted Tomcat, everything worked.