To the broader issue of wildcard support, maybe it's a combination of the equals() and isCompatible() that need to be accounted for. I'll go back to Michael's example.
Given these two providers, let's consider two scenarios.
1. Client sends "text/plain"
In this scenario, although both providers are technically a match, the spec states that we should map to the most specific one. The behavior remains unchanged with what we have today. When you're building the list of possible providers though, you could first check for equals(). If that works, breakout immediately because you have the most specific match (provided that there are no wildcards in the inbound mediatype). If the equals() fails, check the isCompatible() to see if it at least matches based on the wildcard.
Either way, once we found the exact match for "text/plain", we just return that and be done with it.
2. Client sends "text/*"
This is what I think Mike was getting at originally. Since we may not have a specific provider for "text/*", everything that starts with "text/" is a candidate. That means both ProviderA and ProviderB show up in the list. To Michael's question about which one is then selected, I think it's ProviderB aka "text/plain".
Not go chapter-and-verse, but take a look at section 3.8 of JAX-RS. I'm interpreting step 5 to be where both are added to the list, because they're compatible. Step 7 is where "text/plain" is put ahead of "text/*", and the rest just plays out.
At least, that's my interpretation. Dustin brought up the fact that some of this is also discussed in the Accept headers section of the HTTP spec, here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1