I guess the specific incorrect error message is the one that says
global function 'foo' requires that 'Class' conform to 'P'
because there are other ways to satisfy the constraint without making the Class conform to P? For example:

protocol P {}
class ClassA {}
class ClassB: ClassA, P {}

func foo<U>(_: U) where U: ClassA & P {}

func test(x: ClassB) {  
  foo(x) // OK
  foo(true) // error: global function 'foo' requires that 'ClassA' conform to 'P'      // ^ not the only way to satisfy the constraint.
}

The "cannot convert" error message shouldn't be emitted at all, since there is no concrete expected argument type – it's a generic parameter. The requirement failure message should instead say global function 'foo' requires that 'Bool' conform to 'P' or global function 'foo' requires that 'Bool' inherit from 'Class', because the substitution for U in foo(false) is Bool, not Class. This issue disappears if we remove either the Class or P constraint on foo.

I see what you mean. When removing the `& P` from the constraint, the message accurately says "global function 'foo' requires that 'Bool' inherit from 'Class'", but when it's there, the error about Bool not being a subtype of Class is now phrased in terms of a conversion failure.

Since type conversions are done automatically via subtyping (among other avenues), being more specific about why the automatic conversion failed, i.e., that it doesn't inherit, would be better.

Yeah. It appears as if we inadvertently skip recording the requirement failure fix for the primary substitute (Bool in this case) when there's both a conformance and superclass constraint, perhaps causing the U := Class binding to be attempted to salvage the system, hence the misleading automatic conversion failure.