First off, I don’t think seperating the language into “AOT-compilable” and “not AOT-compilable” parts purely based on a function annotation is good. A priori every function should be AOT-compilable, as long as it doesn’t require eval, even type unstable ones (“just” compile all reasonable code paths and put them in your binary. Perhaps deny Any). So arbitrarily introducing a split based on some annotation splits julia smack dab down the middle into two “languages”, which I think most people would really like to avoid.
Second, we can do exactly that kind of assistance today, via the same mechanism that JET.jl and Cthulhu.jl use. They’re even already usable as part of a test suite.
So from my POV, adding such an annotation would just add another “color” of function (if you’re familiar with async functions, where I’ve borrowed that term from), without really adding a whole lot of benefit that we don’t already have or we can’t already get with less disruptive means.
From what I gather you’re looking for ways to have a compiled julia binary, without any runtime code generation, and which tools would help developers work in such a workflow, correct? Wouldn’t it be better for developers if the compiler told them which part of their code is problematic for static compilation, instead of them having to hunt down functions written specifically for that purpose (and thus being unable to reuse the existing libraries)?