Don't current Opera versions announce that they support XHTML while
stating a preference for HTML? Shouldn't sensible content negotiation
only send XHTML in place of HTML when the UA expresses both support for
it _and_ a preference for receiving it?

The notion that you can write static pages in Appendix C-style XHTML and
use content negotiation to decide which content-type header to send with
them really stands a very good chance of coming unstuck whenever there
is an intention to script those pages. A SCRIPT element in a static page
can only reference one URL but a browser receiving an HTML content type
will create an HTML DOM to be scripted and a browser receiving an XHTML
content-type will create an XHTML DOM to be scripted.

The single script file referenced from a static URL in the page will
struggle to accommodate both DOM types (as they need to be scripted very
differently). It is much less trouble (and probably about equivalent
work) to create two script resources, one for each DOM type, and serve
HTML DOM scripts to pages that have been served as HTML content types,
and XHTML DOM scripts to pages served as XHTML content types.
Unfortunately there is little reason to expect a browser's request for a
script to contain information that could be used to negotiate which
style of script to send (a script is a script, is a script, whichever
type of DOM is trying to load it). So serving scripts depending on which
content type you previously sent with the page that wants to load the
script becomes a problem.

Session tracking could be used; remembering which content-type was sent
with the page and then sending a particular script version when the
request came back for the script in the same session. Session tracking
by URL re-writing would impact on the client-side caching of the script
(and you would normally want scripts cached on the client if possible)
and cookie-based session tracking might result in intermediate caches
serving the wrong script type to some users.

And the alternative is:-

- in which you use an explicitly different script URL with each type of
mark-up. It can be served from a cache if available with out any risk of
getting the wrong script for the DOM type being scripted, and without
requiring any additional effort to mach script requests with previous
page requests.

But what has been done here? A requirement to provide essentially static
marked-up content with a script now involves dynamically generating (or
pre-processing two versions of) the pages, writing/testing two versions
of the same script and including server-side scripts (or a considerably
more involved server configuration)(with an inevitable increase in
server load) just to make it possible to serve the same content as HTML
and XHTML, with no perceivable difference to the user's experience of
the results. And that is assuming that all the added complexity works
the way it was intended 100% of the time.

So, we can content negotiate but what is the reward for all of that
extra trouble and expense?

Richard.