My post had more C# bias than appropriate. .NET Native also supports VB. See:
https://msdn.microsoft.com/en-us/dotnetnative. I don't think it yet supports F#, but that's likely on the roadmap.
Reflection is supported on .NET Native Native. See: http://blogs.msdn.com/b/dotnet/archive/2014/05/20/net-native.... Reflection.Emit is not.
There are effectively three codegen strategies: JIT, pre-jit and static compilation/AOT. They all have their own characteristics and reasons why they are a good choice. I can see that you have depth here, but I'm going to provide an answer with more context, for a broader audience.
- JIT has the most flexibility since the code is generated (you guessed it) just in time. This means that the code generated can be specialized in terms of hardware or use a layered approach to codegen (prefer throughput and then CQ for hotter methods). It is also the best for versioning, since the code is always generated in terms of the actual dependencies, as opposed to the ones you happened to compile with.
- Pre-JIT can be very high performance since you don't have to pay for JIT and other related costs up-front, as is the case with NGEN. Depending on the code generated, it may be subject to the fragile base class problem: https://en.wikipedia.org/wiki/Fragile_base_class, as is the case with NGEN. MDIL is also subject to it, but we made the cost to regenerate images very low. There can be a problem of when to generate the images and where to store them. These two issues have been a constant design challenge for us (mostly the former). At least on the surface, pre-jit is much cheaper than AOT, particularly since you can rely on a JIT for the code that you can generate deterministically (at least into a single bit of code) ahead of time (think generics). ReadyToRun (https://github.com/dotnet/coreclr/issues/227) is a project we're working that makes NGEN/CrossGen images more resilient to the fragile base class problem.
- AOT can be very high performance, for the same reasons. We've found that it is even higher performance since you can skip a number of architecural requirements for a dynamic runtime environment. If you couple this with app-local framework and runtime distribution, as is the case with .NET Native, then you also skip the fragile base class problem. Building a high-performance industrial quality AOT system with a fabulous developer experience is a fantastic computer science challenge. We've certainly found it to be that. We're several years into AOT investments and we're finding that it is paying off.