I think @smarter would be the best person to review this. Guillaume, can you take a look? You have thought most about dealiasing and type inference.

@smarter @som-snytt
Have you maybe managed to take a look?

I'll learn something by taking a look. I recently removed dealiasing from Scala 2's typedNew and also contended in Scala 3 with the type of new A.C for C[T] where the unused check sees type [T] =>> this.A.C[T] at #23699

Edit: apparently I already have a branch review/23242...

Sorry for the late reply! So having type aliases influence type inference here was a conscious choice so that users could customize higher-order unification by defining their own type aliases. The logic proposed in this PR is sound, but I worry it's making the rules around type inference more complex. An alternative here would be to use a curried type alias to get unification to do exactly what you want:

//> using dep org.typelevel::cats-core:2.13.0
import cats.Functor
import cats.syntax.all.*
type Result[Err, Res] = [F[_]] =>> F[Either[Err, Res]]
def test[F[_]: Functor](x: Result[String, Int][F]) =
 x.map(identity) // ok

Thanks for the timely comment (just back from grocery shopping). This morning I got up to speed on the code and suspected there might be a user solution, but I'm not used to writing the funny arrow. I thought the point was that "unification", as a convention, already does what I would expect.

I saw that the PR flips canInstantiate in a way that seems obvious. I'll see if I have an opinion about the tweak. Rules for type inference only matter when it seems to infer the wrong thing (as in this case).