actually, the RFC makes a distinction:  representations correspond
to resources that are subject to content negotiation.  variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616.  those entities only become variants
or
representations if there is more than one entity possible for a
resource.

although the language in section 1.3 is a little confusing, I
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.

regardless, the AWWW  abandons the "variant" vs. "representation"
vs. "entity" distinction altogether.  on one hand, the distinction
doesn't really matter.  on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.

but that's just it -- I don't think RFC-2616 adequately *models* what
is happening.  nowhere does it explicitly state that:

200 + Content-Location == 301/302/303/307 + Location

even though we all understand that is what is actually happening.
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.

its not that it is confusing -- that was my point that it makes
perfect sense from an implementation point of view.  having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one

actually, the RFC makes a distinction:  representations correspond
to resources that are subject to content negotiation.  variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616.  those entities only become variants
or
representations if there is more than one entity possible for a
resource.

although the language in section 1.3 is a little confusing, I
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.

regardless, the AWWW  abandons the "variant" vs. "representation"
vs. "entity" distinction altogether.  on one hand, the distinction
doesn't really matter.  on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.

but that's just it -- I don't think RFC-2616 adequately *models* what
is happening.  nowhere does it explicitly state that:

200 + Content-Location == 301/302/303/307 + Location

even though we all understand that is what is actually happening.
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.

its not that it is confusing -- that was my point that it makes
perfect sense from an implementation point of view.  having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one

actually, the RFC makes a distinction:  representations correspond
to resources that are subject to content negotiation.  variants, in
general,
do not necessarily correspond to resources subject to content
negotiation.
and to further complicate the terminology, resources actually return
entities according to RFC-2616.  those entities only become variants
or
representations if there is more than one entity possible for a
resource.

although the language in section 1.3 is a little confusing, I
interpret it
as representations are a subset of variants (perhaps the server or
script
choses the entity w/o considering the various Accept.*: headers), and
variants are a subset of entities.

regardless, the AWWW  abandons the "variant" vs. "representation"
vs. "entity" distinction altogether.  on one hand, the distinction
doesn't really matter.  on the other hand, it does demonstrate that
RFC-2616 and AWWW are not 100% in synch.

but that's just it -- I don't think RFC-2616 adequately *models* what
is happening.  nowhere does it explicitly state that:

200 + Content-Location == 301/302/303/307 + Location

even though we all understand that is what is actually happening.
section 14.14 imbues "Content-Location:" with highly magical
properties not discussed elsewhere, properties that apparently trump
the 30X family of response codes.

its not that it is confusing -- that was my point that it makes
perfect sense from an implementation point of view.  having the
server send a 200 and tell you that it did a switcheroo via
the Content-Location header w/o requiring an additional http
request makes sense from an implementation point of view (one
less transaction).

(and it actually happens a lot -- Apache has implemented a version
of RFC-2295 since forever (which defines that you only get a 300
response only if you explicitly ask for it with a Negotiate: request
header) -- its just that few people witness it.  client send various
Accept.*: request headers and the server responds with the correct
Vary:, TCN: and Alternates: response headers and few people actually
witness it.  I mention this only b/c there is a prevailing belief
that content negotiation doesn't happen a lot -- it happens, but
people just don't see it b/c the client is not redirected (i.e.,
the URL in the toolbar doesn't change)).

the 303 generalized content negotiation does remove the de facto
restriction of occuring on the same server.  That is conventionally
you can only do things of the form: http://foo/a --> http://foo/a.html.
with AWWW 303 style CN you can do:  http://foo/a --> http://bar/a.
but this flexibility does cost you an extra http transaction.

of course, none of this changes your other, more salient points.
I just like to talk http.  ;-)