[neonsunset]

This does not line up with the implementation. You may want to ask in DotNetEvolution or dotnet/runtime discussions as there you can get a definitive answer why something didn't work - most of the time it is best to avoid such assumptions.

Open generics simply propagate type parameters down - T: class produce shared method bodies, as they do with the JIT with the type being passed implicitly. For T: struct the corresponding code is fully monomorphized. This is not related to JIT at all where the main distinction with NativeAOT is when compilation happens.

All generic scenarios are supported. Unbound un-analyzable reflection as well as anything that requires JIT like assembly loading or reflection emit - this doesn't work for obvious reasons.

[nodra]

Only generic scenarios that can be resolved and compiled at build time are supported in NativeAOT. So, the statement that “all generic scenarios are supported” is overly broad. I’ll try to avoid such assumptions :).

[neonsunset]

ILLink has definitive knowledge about the types present in the program, including generic instantiations, which is what allows ILC to compile the program. You cannot introduce new types at runtime when using NativeAOT, and all callsites and reflected upon members are either statically known or brought in by one or another form of annotation. This is not related to JIT because the only difference in generic handling is when the compilation takes place. It is handled by the same compiler back-end being fed the same information. In fact, this also applies to trimming with JIT publish modes. Generics themselves are only tangentially related to reachability analysis. You are misunderstanding the way this works, this isn't Unity's Mono.

Putting in more practical terms - had NativeAOT not supported List<T> where T is an open generic, most hello-world scenarios would not work at all. And yet, somehow, by divine intervention, ASP.NET Core, DapperAOT, Avalonia, Uno as well as MAUI iOS under Simulator, even damn WinForms that was never made with NAOT in mind (with a helper package), and so on and so forth - all complex applications, work under NativeAOT.