Currently only mime-types are used to match highlighting files. This introduces at least two problems:
Assume that there already is a mime type "text/foo" as a sub class of "text/plain", with glob pattern "*.foo".
Now a highlighting file specifies extension "*.foo" and no mime type.
The result is, that a mime type "text/x-artificial-foo" as a sub class of "text/plain", with glob pattern "*.foo" needs to be registered.
Now we have two mime types with same-weight matching glob pattern on the same level (direct child of "text/plain"), and there is no way to tell which one will be returned as the "best match" for a .foo file. Which could either lead to a custom editor type for "text/foo" never be used, or to the highlighting file never be used even when force-opening the file in PlainTextEditor.
There is no guarantee that the glob pattern that is specified in the highlighting file has anything to do with the mime type(s) that it specifies. So, if Qt Creator has a specification for the given mime type(s), it might have completely different glob patterns than specified for the highlighting file.
Additionally, when a highlighting file specifies a mime type that is not known to Qt Creator's mime database, it currently creates a new mime type with the given glob pattern(s) as a child of "text/plain". This then leads to the same problem as in "Highlighting files without mime-specification"
I think the two attributes should be read: Use me if the file has one of the following mime types, or one of the following file extensions. So, matching highlighting files should be done by checking if the file has a matching mime type, and then if the file has a matching file extension.