More comprehensive test case, that also exercises non-empty interfaces:

package main

type I interface { M() }

type myint int
func (myint) M() {}

func f[T comparable, U interface{ comparable; I }](a any, i I) {
        var t T
        var u U

        if a != t {
                println("FAIL: if a != t")
        }
        switch a {
        case t:
        default:
                println("FAIL: switch a, case t")
        }
        switch t {
        case a:
        default:
                println("FAIL: switch t, case a")
        }

        if a != u {
                println("FAIL: if a != u")
        }
        switch a {
        case u:
        default:
                println("FAIL: switch a, case u")
        }
        switch u {
        case a:
        default:
                println("FAIL: switch u, case a")
        }

        if i != u {
                println("FAIL: if i != u")
        }
        switch i {
        case u:
        default:
                println("FAIL: switch i, case u")
        }
        switch u {
        case i:
        default:
                println("FAIL: switch u, case i")
        }
}

func main() {
        f[myint, myint](myint(0), myint(0))
}

CC @randall77

It seems plausible that this could lead to subtle bugs in real code, for example:
https://go.dev/play/p/MQ1qi27IjUJ?v=gotip

Do we understand the underlying issue here? If so, do we have a plan to fix it?

Do we understand the underlying issue here? If so, do we have a plan to fix it?

We chatted about this on Monday and decided to flag this as an error in the compiler for 1.18, with a hope for a more fundamental fix in 1.19

From a conversation with @eliben, it looks like he's counting on @mdempsky or @randall77 to take a look. From Eli – "We decided to flag it as an error because we don't have a good undestanding of how to compare interface values with generic values at this time"

Should be done by release time.

Change https://go.dev/cl/391315 mentions this issue: go/types, types2: disallow interface vs type parameter comparison

Acceptance of https://go.dev/cl/391315 will change this from a release blocker to a bug for Go 1.19.

A better temp. solution might be to report this issue in the compiler proper; this CL is just here as a last resort.

I sent https://go.dev/cl/391374 that fixes some of the cases and give an error for a case that is harder to handle.

I'll let @randall77 and @mdempsky decide which approach to take.

Change https://go.dev/cl/391374 mentions this issue: cmd/compile: use correct type when comparing generic to interface

Sorry, I've been away for a few days.
The problem here, at least for the != test, is that there's an implicit OCONVIFACE that the stenciler needs to see in order to do the comparison properly. I think we actually fixed that at one point, in CL 336992 perhaps? Not sure if there was a regression since. Looks like that CL didn't have a test, unfortunately. I'll look some more.

Change https://go.dev/cl/391475 mentions this issue: cmd/compile: fix transform of OEQ/ONE when one arg is a type param

Change https://go.dev/cl/391594 mentions this issue: cmd/compile: fix expression switches using type parameters

Reopening for backport to 1.18 release branch. There are 2 CLs, 391475 and 391594.

Change https://go.dev/cl/391794 mentions this issue: [release-branch.go1.18] cmd/compile: fix transform of OEQ/ONE when one arg is a type param

Change https://go.dev/cl/391795 mentions this issue: [release-branch.go1.18] cmd/compile: fix expression switches using type parameters

Closed by merging commit 1edc1cc (CL 391794) and commit 2c6a889 (CL 391795) to release-branch.go1.18.