The benefits of many small improvements to the language will far exceed those from a radical re-design, especially when those small improvements align to features in other languages.
Examples abound.
1. Composite string formatting is long overdue; formatting based on []fmt and string concatenation is no longer compatible with rapid application development.
2. String interpolation would also promote the language in the same direction.
3. Built in support for dates--in a way that is compatible with data transfer/acquisition-is long overdue.
4. Integral support for XML, CSV, JSON will promote data/acquisition transfer; so would a standard means of managing relational data. (LINQ for Objects).
5. A report writer that easily writes output will standardize the means of presenting information.
It is a question of priorities; that is by no means straightforward. However, for a language with a shrinking user base, creating appeal for developers in other languages is not an option, it is a critical requirement.
Users have expected functionality improvements in the workspace or interactive sessions. We have moved from 8-bit to 32-bit, welcomed []wi interfacing to COM, []wi interfacing to Windows Forms, []wcall for accessing operating system APIs. []ni, []cse.
Backward compatibility with APL+Win is an issue only if there isn't an automated migration path. Visual APL was probably too radical a leap. Larger workspaces would be a bonus - the real requirement is an APL that is much less workspace bound and documented in such a way that it is more open to new users.