If you're grabbing the constructor as a function, for example, then it's a bit more sensible to use Cat instead of Cat.new. I don't know...it seemed at the time neat to allow a shorthand way of constructing something, but it's kinda wonky.
This is refreshing from other newish (cough golang) languages which pick the "wonky" path, but go on to defend it tirelessly. Keep up the good work.
On the other hand, Lily is a type-safe language with generics. The kinds of "metaprogramming" that you would try to do with Python classes-as-objects might be done in different ways in Lily.
More theoretically, the whole point of types (as sets) was to was to be a qualitively distinct layer of things that could not be mixed up in logically paradoxical combinations with other objects. That abstruse point of logic might or might not have practical implications for a real-world programming language.
My immediate reaction to the name "Lily" is positive, evokes a sense of calmness, and suggests an elegant, well-structured set of tools.
Regarding constructor syntax, probably "Cat.new()" is more common or conventional. I kind of like "Cat()" as it's less verbose, noisy. However I see what you mean about allowing classes as values, if not entirely clear to me how that feature would absolutely demand one syntax over the other.
I agree with other comments, Lily is an outstanding one-person effort! That its creator is self-taught only adds to its charm.