Magnolia sets Content-Type header right in the ContentTypeFilter (which is #2 filter in default config).
It finds out the MIME-type based on the extension using the MIMEMapping. This caused clients some problems (see MAGNOLIA-6367).

IMHO the correct approach is to set the Content-Type header where the content is actually generated - so mostly in renderers.
ResourceTemplate already allows setting up contentType, so I propose to move it up to RenderableDefinition API so that all renderers can react to it.

Problems this change would cause:
The ResponseContentTypeVoter relies on Content-Type being set. Solution to this would be re-purpose this listener to examine request extension instead, since that is what it does anyway.
Another trivial problem is wrong MIME-type of JCR-exports (application/octet-stream instead of correct application/xml.