Examples:

void 'test'

COMPILE ERROR: Unexpected ClassType
        at :Unknown Source:0.0

void @test

COMPILE ERROR: Expected classtype, but received type void instead.
        at :Unknown Source:0.0

auto 'test'

COMPILE ERROR: Unexpected ClassType
        at :Unknown Source:0.0

Note: if any type is written in the script and nothing else, there will be no errors

2eae885 I fixed the other example and related issues with unknown targets on assignment.

Adding code targets for CClassTypes in scripts is still something that should be considered, but it's a more extensive change.

Just to clarify, the compile errors are valid, only the source (Target) should be known here instead.
Regarding the note: It is indeed true that you can currently use classtypes in places where it might make no sense. Generally these get converted to the string representing the classtype (e.g. value int would convert to string ms.lang.int), unless the function really expects you to input a classtype there. So while a script with only a classtype in it doesn't make much sense, it's valid code.

This bug is caused by using singular cached CClassTypes with an unknown target. These are created here.
One possible fix is to not use cached CClassTypes when a target for them is known, but this breaks any == CCLassType comparisons, which could cause annoying bugs.
Another solution is to cache some ClassType instead of CClassType, and use cached ClassTypes as non-Construct within CClassType instances. User code would keep containing CClassType instances, but all code that handles these would do checks using the actual ClassType they represent.

452cde8 I fixed at least one place this occurs by using the trailing data Target instead of the ClassType Target. It was more appropriate in that context anyway. ClassTypes having an unknown Target is still an issue, so this isn't "fixed". But in regards to the above errors, only the Expected classtype, but received type void instead. one is still exists.