Your list is way too long, it mentions an important item though, but misses another very important item. Let's see.
* Multi-threading: This has been ALWAYS a pain point for Nim * Concurrency: This is being addressed, finalize it properly Pragmatic approach: What do Rust and C++ offer for that? could Nim borrow from them? If not, is it a ARC/ORC related issue? Theoretic approach: The stack based model (transient data on the stack, permanent data on the heap) does not fit well for multithreading/processing. The memory model needs to be reversed: Permanent data on the stack (= functions with state), transient data on the heap (providing a dynamic environment). Therefore, PLs need to support a stackless model. Either as an add-on, a DSL. Or as a core design. The latter will be the best. Now to the most important point. Nim as an atomic vs a molecular language As a classic language, it supports the atomic design: A compiler takes a program part lets say P1, transforms it into a term-like representation combined with a substitution list, let's say S1 (in fact, it is a partial environment). (C,_)(P1) => (C,(S1)) and waiting for another program part P2 : (C,(S1))(P2) => (C,(S1[S2],S2)) , now waiting for a P3. The compiler builds the S2 using S1, S2 depends of S1. But at the same time, S1 gets further instantiated with S2. Complexity becomes quadratic at least, see : (C,(S1[S2],S2)) (P3) => (C,(S1[S2,S3],S2[S3],S3)) and so on. It is an atomic design because everything depends of everything. This will lead to combinatoric explosion, if the language is complex enough - e.g. C++. Successors of C++ (Java and later) therefore aimed to avoid it with "Boxing" \- type erasure everywhere. So, the lifting of a Pn into a Sn will not affect the previous Si anymore. These languages follow a molecular approach: Program parts preserve their independency. They could even go so far to bind a dynamic program part (available at runtime only) to the static part, so runtime checks need to be added. Node.js can do that (it compiles Javascript and binds to Javascript) and Swift does it too (it binds to the dynamic runtime of ObjC). Very, very demanding though. C++ will not go so far. Within its last revision, it will introduce modules instead, aiming for better code separation and separate compilation especially. So, what is the way for Nim? If the goal is "Nim must win every speed contest" -> stay with the atomic design. If not, it would require a module system. How? Pragmatic approach: Borrow from C++'s export modules. It is not relevant if it is "elegant" or "ugly". It is consistent (or it seems to be, I can't give a final answer yet) . It has do be done anyhow, because gcc will support modules too (rather sooner or later). Theoretic approach: Go beyond C++ modules and add parametricity. Type parameters would appear with two polarities here : positive (constructors) and negative (destructors). Depending on the polarity, interfaces, concepts and typeclasses could be uniformly represented with them. The extension is not trivial however and might lead to unexpected results. Java's generics are a famous example for that. With a molecular design, Nim will achieve a very good position to compete with any language at the industrial level. (As long as this is a goal )
