This seems to be a recurring theme with Lisp implementations. Reddit switched from CMUCL to Python (threading); Vendetta Online switched from SBCL to Erlang (GC/memory leaks). Other people have hit major snags e.g. with Haskell/GHC runtime bugs (Wager Labs; switched to Erlang). Use a massively complex runtime, hit bugs that can't be fixed (in a start-up timeframe, anyhow)?
Not necessarily -- some organizations would patch it themselves in a private branch just to maintain an edge, assuming they have the expertise in-house. I've done this before with GPLed libraries. That's assuming you can even track down the problem -- Vendetta Online couldn't pin it down well enough to submit a coherent bug report (in fairness, SBCL is a monstrosity; just as a comparison, how many Rails developers could track down CRuby bugs?).
> how many Rails developers could track down CRuby bugs?
Probably a lot of them, if they tried. Because Ruby is so poorly specified, I frequently read the interpreter source code to figure out how things are supposed to behave. CRuby is really well-written in some ways and really poorly-written in others. It's poorly written in the sense that it's a painfully slow line-by-line interpreter. It's well written in the sense that the code is very clean and well-organized: I can usually find answers in the source faster than I can find answers in the pick-axe book.
This is a recurring theme with cutting-edge software. Arc is probably exercising parts of the mzscheme code that haven't been exercised before. Bugs will be fixed and things will be better.
I rewrote my senior project in Common Lisp two weeks before the due date because I was running into too many bugs in mzscheme. Then I switched from clisp to SBCL because of a bug in clisp.
Source? With the bashing Python is getting because of the GIL, it surprises me that someone would switch to Python from elsewhere for any reasons related to threading.
