The problem is to render the markup for an ajax request two ResponseWriters comes into play:
PartialResponseWriter wraps HtmlResponseWriterImpl. JSF 2.0 spec section 188.8.131.52 says this:
"... JavaServer Faces provides javax.faces.context.PartialResponseWriter to ensure the Ajax response that is written follows the standard format as specified in Section 1.3 “XML Schema Definition for Partial Responses”. Implementations must take care to properly handle nested CDATA sections when writing the response. PartialResponseWriter decorates an existing ResponseWriter implementation by extending javax.faces.context.ResponseWriterWrapper ..."
Which seems obvious, now take a look at section 13.4.4
With this two descriptions we can conclude that
MYFACES-3339 is a bug and needs to be fixed. Historically, there was some issues on both ResponseWriter implementations, and the old code was a workaround. But later after solve issues we found the right "combination".
Now take a look at section 8.1, in the part that talks about createResponseWriter:
"... The contentTypeList parameter is an "Accept header style" list of content types for this response, or null if the RenderKit should choose the best fit. [P1-start-contentTypeList]The RenderKit must support a value for the contentTypeList argument that comes straight from the Accept HTTP header, and therefore requires parsing according to the specification of the Accept header.[P1-end] Please see Section 14.1 of RFC 2616 (the HTTP 1.1 RFC) for the specification of the Accept header. ..."
The same description is on the javadoc and basically it means if no contentTypeList the RenderKit should choose the best fit but later says derive it from Accept HTTP heade. Since the header sent by primefaces is:
Accept application/xml, text/xml, /; q=0.01
And HtmlRenderKit has two modes xhtml and html, the best match is xml. In theory the client side is the one responsible to send the proper header, because in that place it is possible to know which contentType when the page was rendered at first.
Since this behavior is specified by the spec, we can't change that part. Since there is a valid workaround adding a RenderKit wrapper, create a config param doesn't sound good.
It is true send <!-- --> is valid, but according to the spec text/html should be sent into accept header so HtmlResponseWriterImpl could choose the right match.
Looking more carefully, maybe the problem is we are using xhtml mode for application/xml, text/xml, but it should be only used if Accept header is application/xhtml+xml. I'll check it with more care to see if we have a problem here.