This is due to caching the resolution of GetType.GetTypeClass, which appears as identical Ident trees in the parent of Thing and in the RHS of e.

From the superclass context of Thing, it incorrectly cached at an outer context, where the lookup from e found it as a definition at higher precedence than the import.

A couple of notes to self or reminders:

The trees don't distinguish whether the ident is due to implicit search or import. The comment at typedIdent is false, because the elidable prefix does not result in a Select. That is, I'd expect the RHS of e to be a typed selection.

Scala 2 certainly transforms to a select:

Select(Ident(p.GetType), TermName("GetTypeClass"))

or -Yprint-trees:format

          ValDef( // val e: p.GetType[p.Class]
            0
            "e"
            <tpt> // tree.tpe=p.GetType[p.Class]
            "GetType"."GetTypeClass" // implicit val GetTypeClass: p.GetType[p.Class] in object GetType, tree.tpe=p.GetType[p.Class]
          )

This doesn't matter for Scala 2 -Wunused:imports because the typer records the imports it used for lookups.

Removing the loopOverPrefixes doesn't break any tests. Either that progressed elsewhere or a better test is needed. (I think I restored that code at some point last year, but I don't have commit history to see why.) (Edit: https://github.com/scala/scala3/pull/22751/files)

Is there any plan to fix this and #22971 for 3.7.0 release? Both issues have PRs waiting for review.

If this is not fixed, how can I make my project compile other than not using -Xfatal-warnings or -Wunused:imports?

I did not find a way how to disable import warnings selectively, as I was not able to make Wconf match properly on the multiline message.

@OndrejSpanel I think lint fixes will not be "backported" to the branch during RC at this point.

Because it is "just a lint", the immediate issue is that -Wconf isn't working for you. For imports, Scala 3 now has origin=my.pkg. That matches the import "selector", and its purpose is to work where @nowarn fails.

Your other question about matching multiline messages will require some testing, but supposedly the Wconf expression is "just a regex". (Edit: the regex need match only a subsequence of the text, i.e., findFirstIn.) I'll either follow up here or open a new ticket if I can't get it to work.

If you post your -Wconf here, I'll look at it. I would agree that wconf is a "cottage industry" unto itself.