AI read on such a case:

Why the asymmetry exists: STC's method selection filters candidates by visibility, so a private static method of another class is rejected up front in both modes. But its property/field resolution doesn't enforce visibility — it happily resolves P.M and infers Map. Under @TypeChecked that goes unnoticed because runtime dispatch is dynamic and Groovy is historically lenient about private access, so the code even runs. Under @CompileStatic, StaticTypesCallSiteWriter has to emit a direct GETSTATIC, re-checks accessibility at codegen time, finds no bridge method (those only exist for nestmate-style relationships — same class, closures, inner classes), and refuses with the late, non-STC-flavored "Access to P#M is forbidden". The workaround (@PackageScope, or exposing a getter) is straightforward.

Probably should be fixed - probably a breaking change for some edge case.

Does the fix also cause problems reported in bunch? I made our code compile under STC, then I switched on static-compile and I only get some findings in one file per compiler run right now, very tedious. 😞