General comment: given this:

typealias MyNumber = Number
foo: Class<MyNumber> = Number

This seems like an incorrect error, because MyNumber is just an alias for Number.

–– Pkl Error ––
`Class` type arguments may only be class types, module types, `unknown`, or `module`.

9 | foo: Class<MyNumber> = Number
         ^^^^^^^^^^^^^^^
at test (/Users/danielchao/code/apple/pkl/.dan-scripts/test.pkl:9)

Might also be okay to not throw for type arguments which don't point to classes. In these cases, the type would just never typecheck, and it would behave just like the nothing type. For example:

a: Class<Foo?>
b: Class<"foo" | "bar>

General comment: given this:

typealias MyNumber = Number
foo: Class<MyNumber> = Number

This seems like an incorrect error, because MyNumber is just an alias for Number.

Can you say more about how this would be useful? The only case I can think of is the compatibility shim typealias when a class is moved out into its own module.

If this was supported, it would only work for aliases to bare class types, which is of limited utility. An alias may hide that type is not an ordinary class and result in an error (as-is) or a nothing type (as you suggest below), especially if a library author later refactors an alias to include a constraint where one did not exist previously.

Might also be okay to not throw for type arguments which don't point to classes. In these cases, the type would just never typecheck, and it would behave just like the nothing type. For example:

a: Class<Foo?>
b: Class<"foo" | "bar>

Again, I think it's more surprising that users could inadvertently build a nothing type without realizing and have all their type checks silently fail. This would still be a breaking change compared to the existing behavior (where these are essentially erased to unknown) and I'd prefer to break in the direction of providing helpful user feedback than silent and potentially-surprising behavior.

Can you say more about how this would be useful? The only case I can think of is the compatibility shim typealias when a class is moved out into its own module.

An invariant of a typealias is that: on the type level, it just stands for its aliased type; therefore Class<MyNumber> should be the same as Class<Number>.

Again, I think it's more surprising that users could inadvertently build a nothing type without realizing and have all their type checks silently fail

I'd expect the failures to be loud, rather than silent! If you try to assign anything to Class<Foo?>, Pkl throws an exception. Also, I'd expect that any usage would also be caught statically (e.g. red squiggly lines in the editor during assignment). We can also add a warning diagnostic if you declare Class<Foo?> (or similar).

Updated this to unwrap typealiases during class calculation, so aliases (to aliases)+ to classes now behave as if the underlying class was used directly.

Also updated this to error at runtime rather than during ClassClassTypeNode init (or alias instantiation) with a hint that such type checks can never succeed. I think the errors are less helpful in cases where the Class type node or the type arg are behind aliases (since previously it relied on the same machinery as ReferenceTypeNode's constraint-in-referent checking). The only real difference other than error message content is that "bad" type annotations that never execute never raise errors. I can live with either approach, but I think the runtime errors aren't as good.