It couples your program design with the JIT compiler’s internals. From a software engineering point of view, I think this is really one of the worst things that can happen to a software. You end up structuring your code with the compiler’s convenience in mind.

This coupling is found in any language, regardless of AOT or JIT compilation strategies. On one hand adding user-defined domain-specific optimizations (such as rewrite rules in GHC) can help improve performance and increase the level of abstraction, but then again, you couple yourself to additional constraints under which optimizations may or may not occur.

There’s an old yet IMHO under-appreciated technique for taking statically-known inputs into account while compiling programs. It’s called “partial evaluation”

I am not sure it is under-appreciated. It's received a lot of research focus and is still actively researched. It just doesn't seem to find its way into actual wide-spread use. I know too little about why exactly, but I don't think there is a lack of interest.

The goal of partial evaluation and supercompilation (frankly, I still don't understand how that, at its core, differs from online PE) is a noble one but traditionally, that has forced users not only to consider traditional compiler behavior but also understand how the employed partial evaluation mechanism works and where it works, how to structure programs, and figure out domains where it makes sense.

This is again a very powerful concept, and only recently I started to appreciate it’s potential11. IMO, MSP is missing a “killer language”12(and also a “killer application” but I think that follows the language) and I’m hoping to make some progress on this front in the future.

Regarding languages, there is LMS in Scala, and I think MetaOCaml is quite usable and "safe". However, the former has more practical examples, I believe. Killer applications are parser combinators, DSLs, HPC, etc. essentially anywhere PE would make sense but is made more explicit (and to be done at run time).

I define a sufficiently smart compiler not as a completely automated program, but as a toolchain. This toolchain has a completely automated compiler, but it also gives programmers tools for runtime code generation, and for teaching the compiler domain-specific optimizations.

For related work you might want to look into the concept of "active libraries".

Anyway, good luck with your research. However, I would have liked to read more about concrete directions or issues you want to tackle.