After quite a bit of re-reading this is my interpretation.
To me, a media type must match to the most specific media range or media type that is defined in the Accept header.
This means that given an accept header:
Accept: text/*, text/plain, text/plain;format=flowed, */*
and a media type text/plain;format=fixed, we should associate the quality of text/* rather than */*.
There is then an example to illustrate this in the RFC.
What I am interpret from the RFC that is less explicit is: when given a choice of media types, the media type that is associated with the highest quality is chosen.
In the RFC, there is this example:
Accept: audio/*; q=0.2, audio/basicis interpreted as “I prefer audio/basic, but send me any audio type if it is the best available after an 80% markdown in quality”.
I assume if I tweak the example, this should be true:
Accept: audio/basic; q=0.2, audio/*is interpreted as “I prefer an audio type, but send audio/basic after an 80% markdown in quality”.
Meaning that given the choice of audio/basic and audio/mpeg, I prefer audio/mpeg.
HttpRequest.get_preferred_type() returns audio/basic as the preferred type here. This is because audio/basic is a more specific match within the accept header media ranges/types than audio/mpeg but I think the specificity should only be taken into account when determining the quality.