Considering that nitty gritty compiler features like that were implemented by Quigibo and I frankly am still not entirely sure how his code for them works, I think I'd have to pass on implementing that.

I think the Axe 1.x version line is coming to an end anyways, so putting work into adding features to the actual compiler, which I hope to largely rewrite, would be a fair amount of work for code that would probably only ever exist in one or two versions of Axe. I hope to redo the general library system to be a more robust in the next major version of Axe, so I'll probably implement something that provides the same functionality as your suggestion, just in the different library format.

At this point, I'm looking to collect ideas for the future of Axe, but it'll be a ways off until I can implement them.

That is very much the ideal for the future of Axe.

shmibs, with the changes they're discussing, things like dispgraph, zeros(), and, depending on how extreme they want to get, + and -, would be axioms.

I don't know, having every word but axiom includes available would be handy if you wanted to use Axe's compiler as the base for a different language. You could completely change how every part of it works.

Axe is not a C-style language as it currently stands. C style languages support more features, and tend to have more bloat. It doesn't even use similar syntax.

By the way, are there still possibilities of a color Axe in the future?

Will Axe 2.0 still be programmable on-calc though? Since DCS 8.0 RC2 came out, I have been mostly programming on calc rather than Source Coder, since I can test my stuff faster (jsTIfied doesn't run xLIBC well).

But that'll still be awesome
Also, it might be easier to use if you had a custom editor with all-custom tokens, one that comes with the axe app, that way you are not stuck with stupid TIOS stuff