While working on the design of this language - "Turned C" (Ↄ) - I have always had some plans for the future of the language in mind, most notably that it should only hold the programmers hand enough to protect from the most egregious and easiest to hit errors, such as the null-pointer dereference. But other goals included having the language be capable of being implemented on any playform, from the smallest of 8-bit micros that could host the compiler to the most powerful of machines — no variation should be excluded, not even the so-called "managed language" types like the JVM or .NET familes — and that the language should contain features enough that well written programs could rewrite their code at run-time without having to resort to machine-specific assembly languages and even compile, on their own, fragments of new code presented to them through the proper interfaces.
Before I began serious work on the current (though incomplete) proposal for the languages syntax and grammar the last two were stretch goals, things that probably would turn out to not be possible without really mangling the language into an unrecognizable form. However, with the prompting from @Bethelles on Discord, the latest revision of the language truly sees functions and data as being exactly the same thing, meaning that it should be possible to, at some point, allow the composition of functions and their more complex (and as yet undefined for syntax) big brothers at run-time - combine this with reflection that also has something similar to the "ASM" library available for Java and you have a language where the programs actually can rewrite themselves at run-time.
The issue then becomes one of actually supporting the language in what is generally referred to as a "Standalone" environment — that is, running by itself on the hardware with no operating system and possibly nothing more than the machines firmware there with it. That could mean it is providing the "kernel" of the operating system or it could even be that it is the firmware of the device itself. Not that what it is actually doing matters, what does matter is that supporting the more advanced features of a language will add to its overhead, in terms of the amount of code as well as its complexity. In traditional, plain C the language is defined in such a way that it is entirely self contained and you have to provide anything that is beyond pure computation or moving things in memory; In C++, to use it as a "Standalone Language", you have to provide some functions that are normally found in either the C++ setup code or the C++ Standard Libary — what this means for Ↄ is that runtime function composition, especially when it begins to use reflection and similar to inject the new functions or replace existing, and runtime evaluation of new chunks of source code will require similar library assistance.
For "Hosted" uses this can be handled as in C++ — with the standard library providing all the features and them being dynamically linked in — but for "Standalone", as we have been discussing, these functions would have to be provided by the end-user and built into the resulting code. This might not seem like a major issue, as RAM and non-volatile storage of various types is becoming cheaper and more plentiful as time passes, but one of the goals is for this language to be able to have applications written in it run on even the most meager of 8-bit microcomputers and some of those, such as the PIC and AVR families, can have less that a megabyte of RAM and ROM combined.
At this time the only solution I can see for this would be the introduction of "profiles" - various restrictions on the language and its features that are tailored for things like "Standalone", "Basic Hosted", etc... That meaning that, for example, in the "Standalone" configuration a lot of the features that might bloat the final executable in size or memory use are turned off, some parts of the optimization process get tuned differently to take into account the fact that hardware can change state separate from what the software might have recorded and things like "eval" and function composition become unavailable as the support they require is removed. Other configurations, such as one meant for "secure operation" might also turn off function composition and "eval" as well as adding runtime bounds checking on array types and restricting open memory pointers. A solution of having "language profiles" could even be extended so users can define the exact language features they require for their code — or a company could, to enforce their internal requirements on program safety and the like.
In the end, however, this comes down to a matter of whether any of the stretch goals for Ↄ are ever actualized. The simple truth is that they may have been stated and planned for at some point, but actually making them happen in a compiled (instead of interpreted) language running on "real" hardware (whether its a virtual machine or not) is tricky and the only language to have anything like it, currently, (that I have personal knowledge of) is Java, through ObjectWeb's "ASM" library.