Here's an [RFC](https://github.com/nim-lang/RFCs/issues/361) and here's a [PR](https://github.com/nim-lang/Nim/pull/10781) \- the latter a victim of the fine stable bot .
> Can we change so that we don't need compiler flags to turn on threading by > Nim version 2.0?, at least when ARC/ORC are used Yes - and we've started laying down the foundations of a plan of how that can happen - it's not that complicated really: * introduce a version where one can opt-in to the new world where the baggage of the current broken threading support is not present, but the core primitives that enable people to build powerful libraries are * in the next version, more vocally deprecate the old behaviour - people have now had a release cycle to develop solutions for the new world - in this release cycle, _[users](https://forum.nim-lang.org/postActivity.xml#users) of the old threading world can start migrating * in the next version, "maybe" flip the default of the threads switch - now people have a new home to go to, they've had time to pack and so on * finally, release nim 2.0 which breaks the old code and introduces the new world, remove the switch altogether, along with the headline orc/arc support, which regardless of anything else, de facto requires rewriting most **good** nim code anyway. The above is what a "common sense" interpretation of the [new policy](https://github.com/nim-lang/Nim/pull/18541) regarding not breaking std lib frivolously could look like.
