I think this is a slightly dangerous idea if not done right. I hope this does not become what Perl 6 was to Perl. Another concern is that this could make the core team reduce their focus on other key areas impacting the wider adoption of nim, such as tooling (which IMHO should be the top priority).
That being said, if I we ignore those concerns I would make a few proposals (which I hope you take with a grain of salt given that I am a really basic and only occasional nim user): * Make not nil the default (i.e. make "nillability" and opt in feature). * Make style insensitivity an opt-in feature (at import time) and make it an error to use different styles for a particular symbol on the same file. * Remove std lib duplicates (e.g. replace both re and nre with a pure nim re library) and inconsistencies (such as newSeq and newString for example by adopting arne's solution from <https://forum.nim-lang.org/t/9021>) and improve the std/lib without being limited by backwards compatibility concerns. * Review every existing experimental feature and decide if it is worth it or not. If it is make it a first class language feature. If it is not, remove it. For every experimental feature that is kept, look at the other, existing existing nim features and see if they can be combined or perhaps even replaced by the experimental feature. * The nim memory management story is and specially "looks" way too complicated due to the many options available. Thus I'd remove as many memory management options as possible. Ideally I'd only keep orc, arc and none, but perhaps go needs to stay if that is needed for interoperability with go; and maybe boehm also needs to stay for performance reasons? although I hope with enough work orc could also replace boehm? * Take a critical look at the Nim Manual and look for features that overlap too much. The language is a bit too big IMHO. Are there features that overlap due to historical reasons (i.e. because there was no other way to add them to the language)? If so, maybe there is some way to simplify the language? There are a few more things that I'd like to see that maybe would not require breaking backwards compatibility, such as: * Remove the limitations of the method call syntax. * Add first class (i.e. built-in) support for multi-threaded programming, and make language changes if needed. * Add first class (i.e. built-in) support for pattern matching (and if needed, make changes to the language to achieve that goal). * Add a shorthand for defining sum types without having to manually define a discriminator (I know that this seems that it goes against my suggestion of simplifying the language, but it would simplify the use of sum types for most users). * Adding nimpy as a built-in (or at least officially supported) module would be (IMHO) a _[very](https://forum.nim-lang.org/postActivity.xml#very) powerful way to promote nim as a companion / replacement to one of the (if not the) most popular language in the world. Not sure if nimpy can be considered mature enough but if it is this would be great.
