it was a very nice TMS enhancement, when TMS developpers decided to ignore a discrepancy between options xml and pre-processing tool in a TMS content type setup.
And the decision that the pre-processing tool specified in the options xml over the one specified in the TMS content type, is very helpful most of the times.
The only issue with this is that if there is such a discrepancy between options xml and pre-processing tool and none of them matches, TMS might take any default file type available in TMS.
Let me give an example: You set up an XHTML content type, using XHTML processing tool, but XML 1.3-based options xml. By accident one of the HTML files is not a valid XML file. Normally, a TMS user would get an Exception, because XML validation failed.
But in case of such a discrepancy, TMS will switch to HTML 5 processing tool, even if this file type is not set up in the config, which may lead to serious issues when delivering back the file to the client.
Therefore there should always be a warning in the task history making the engineer aware that there is a potential issue in the TMS content type definition.