In my opinion, the biggest problem with Smalltalk is documentation (and perhaps rigor). It's the only oral tradition in programming, and you'll never win over a significant chunk of professional programmers with "we have no documentation, just read the source," which has always been the basic state of documentation in the Smalltalk world.
Along those lines I would suggest creating a way to formally differentiate between private and public methods and perhaps formally define interfaces, so that you have more opportunities for implicit documentation. That may be detrimental to the spirit of Smalltalk, but unless the spirit of Smalltalk is willing to accept some concessions you're not going to see much change in the status quo.
When I did Smalltalk development, documentation was never an issue. In fact, in always every development environment/language that I've programmed, I'd always felt handicapped if I was not able to browse the source. Given the choice, I'd definitely prefer sensibly written source code over written documentation.
That said, perhaps this doesn't work for the significant chunk of professional programmers, and most would agree that Smalltalk's chance to take over the world has passed. We should also ask ourselves if we dumb down every tool so it is usable by a significant chunk of programmers (note that I don't say professional programmers, because that's besides the point here), what are we left with? There's plenty of tools to choose from.
I like being able to browse the source too--in fact, I depend on it for debugging Java programs. But that has never been considered "the" documentation for Java, and in many cases (I'm looking at you, Morphic) it is the case with Smalltalk.
If the Smalltalk community wants to remain small, insular and essentially irrelevant then they shouldn't change anything. However, if they want to win people back, it would be a good idea to take stock of what the rest of the world is up to and consider adopting it rather than insulting it. Clojure is conquering the Lisp world today largely by absorbing modern FP techniques, a modern base and adding clever bits of syntax--changes that would have been heavily derided as unnecessary by the traditional Lisp community.
When your community is small, self-selected and indignant, it's hard to know what changes will make your product more appealing. But defending a lack of progress and chalking low usage up to the inferiority of other programmers is insane, especially in a world with increasing numbers of Haskell programmers.
Redline is very much lacking in that area. When we shore up some code related stuff, I am going to working hard on documentation that exists outside the code.
I can say, we are aiming for 'standard' Smalltalk compatibility in version one and have had many discussions around diverging and becoming more of a 'inspired by Smalltalk' down the road.
There have been numerous discussions around things we would like to add, change etc. Ideally, we want to maintain operability with other Smalltalks but that takes a back seat to building a great tool for the future.
We'd welcome participation in getting us to V1 (code, documentation, web design, whatever) as well as participation on the mailing list for coming up with what the 'next gen' of a Smalltalk like language would look like.
Along those lines I would suggest creating a way to formally differentiate between private and public methods and perhaps formally define interfaces, so that you have more opportunities for implicit documentation. That may be detrimental to the spirit of Smalltalk, but unless the spirit of Smalltalk is willing to accept some concessions you're not going to see much change in the status quo.