Last time I tried I had troubles. My understanding is open generics (like List<T>, without specifying T) don’t fully compile because Native AOT lacks a JIT to handle unspecified types at runtime. Closed generics work fine, though, as they’re fully known at compile time. Am I wrong in my thinking?

You're assuming a workshop where there's just one significant app. The last several places I've worked there were dozens of apps, microservices, and APIs; some of the old and stable APIs were .NET Framework and those never needed to be touched. We built all of the new hotness using .NET Core, Blazor, and whatever the JS framework de jour was, all without needing to touch the old, stable, and working Framework code happly humming along in its VM.

> Staying with .NET Framework is a factor that increases talent attrition

100% this. If a company is not willing to move the product forwards because "there is no need to" then I would be looking else where. .NET Core will be a decade old very soon and a company not willing to move to that tech stack is just pure neglect.

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.