I would (again) just be cautious about a coercive type system. If there is a well-supported “variant” variable type, then users can decide for themselves when/how/to what extent to use compile-time type checking. If not, then users are effectively compelled to buy into strong typing, whether they like it or not. That seems counter to the general SC ethos. (Or, concretely, consider the way that NodeProxy sources can be functions, or patterns, or symbols, or role mapping associations. If strong typing is enforced, then we have to have method overloading (“yay, let’s write source_ five times”) and maybe Java interfaces, and my flesh is crawling just thinking about it.
I tend to think, rather than redoing work that other languages do well, it may be a more effective use of developer resources to write really good server etc abstractions in another language.
Also, realistically I don’t see us fixing the last few remaining really nasty interpreter bugs.
It would hurt if I had to reimplement my toys in another language, but we’re not language design specialists.
A more modular architecture for sc in general, with a smaller “core”.
Pure Data may be taken as a cautionary tale here, where the core is way too minimal. The Pd community has a curious ambivalence: otoh proud of the way that externals solve the limitations of minimal core, but also skeptical of reliance on externals.
hjh