Hi Ken, could you think in some concrete example of what you consider a common non-thread-safe code to justify not enabling it by default?
I guess most people, with background in other frameworks and languages, will indeed expect their web application to be multi-thread.
It was actually a surprise for me when I first realized Rails wasn't multi-thread the first time I used, when it didn't support the threaded model yet.
So, maybe Rails still doesn't enable multi-thread by default for historical reasons, like MRI Ruby 1.8 poor performance in threaded environments due to a lack of support of system threads (only green threads supported) and the lack of support of Rails itself in its first versions.
But JRuby has always support great concurrency and now that MRI 1.9 has better thread support too, maybe the only reason for not enabling the "config.threadsafe!" under production by default is just a historical consequence.
Actually, I've seen some people working to make "autoload" thread-safe in MRI so that it could also be enabled for development mode after a while...
Maybe Rails 3.1 would provide a great opportunity to change this default.