Making Vely understand C, at least insofar as necessary to prevent issues like this is something that I might add, and it probably wouldn't cost that much. It's definitely worth a look.

From a purely functional perspective, assuming Vely statement is placed properly in a functional context, understanding C (as in parsing and then parsing Vely within) might not bring much benefit. Syntactically speaking, Vely is built to not require much about host language. Though, Vely understands enough to emit meaningful messages, such as in the case of writing:

if (cond) vely_statement

where you will get an error that will prevent code from doing unexpected things. There's quite a few of those safeguards built-in.

Being embedded, Vely is a compromise. That was the goal to preserve pure C performance.

Beyond the above, one can still do anything that C can do and that may not be safe; but if Vely is used for what it does, the chances of that go down. Being able to rapidly do stuff in C that is richer and safer is the plus side of it. Without a compromise with being embedded, it would be yet another language that does everything great but with ever declining performance.

And that is fine, if such loss of performance and increased footprint is acceptable; there is nothing wrong with that. Vely's niche is to stay in best performance bracket, and yet bring that performance to general and web application development.

By that I mean a direct native executable from either pure C or embedded statement producing shallow and performant C, without layers of other languages intertwined (because in the end anything is always a native executable even if it has layers of byte codes, interpreters, alone or mixed with native extensions).

There's some truth to all of that to some extent.