From feedback
For some reason it tends to pre-select import completions over regular ones.
It seems the reason unimport one is favored in this case is because it's considered a better match based on current algorithm (which takes suffix "<>" in to account as well)
I've hit this a lot working with the roslyn APIs, especially in unit tests in the compiler layer where there are 4 different InvocationExpressionSyntax classes in differing namespaces.
I've also ran into this issue. I'd like the local LastReturnedResults to be selected:

I still want the exact match to be the preferred item. In this case, however, we have two imperfect matches. One of them is a substring match, and another is a camel case match. I would like locally available variables to have priority over external items who also have imperfect match kind.
however, we have two imperfect matches. One of them is a substring match, and another is a camel case match. I would like locally available variables to have priority over external items who also have imperfect match kind.
say i have a prefix match with an existing symbol, and an exact match with an import-symbol, which should win?
The 'exact match' seems better (it's exact after all), but a user could have easily just wanted to write a quick prefix that would normally hit the existing symbol.
I think we shoudl basically always defer to non-import matches. Because that's the behavior the user would have gotten prior to import-matches being an option. So import matches (similar to extension methods for the compiler) are always 'second tier' results. They're to solve a problem if no existing symbols solve the problem. This also forces users to be more explicit about selecting them, indicating awareness and acceptance of the addition of the import.
I think we shoudl basically always defer to non-import matches
I like the predictability of this approach.
After all, user can use arrow keys to select desired item, or keep typing until local variable gets filtered out.
Most helpful comment
say i have a prefix match with an existing symbol, and an exact match with an import-symbol, which should win?
The 'exact match' seems better (it's exact after all), but a user could have easily just wanted to write a quick prefix that would normally hit the existing symbol.
I think we shoudl basically always defer to non-import matches. Because that's the behavior the user would have gotten prior to import-matches being an option. So import matches (similar to extension methods for the compiler) are always 'second tier' results. They're to solve a problem if no existing symbols solve the problem. This also forces users to be more explicit about selecting them, indicating awareness and acceptance of the addition of the import.