Well, all popular scripting languages (Python, Ruby, JS*, Lua**, etc.) allow “declaring classes on the fly” and replacing existing classes.
In Python, classes are refcounted, so that old Foo instances still refer to the old Foo class while new Foo instance refer to the new Foo class. The same goes for JS and Lua. I would consider this mostly unproblematic.
(In Ruby, replacing classes actually seems to change existing instances (!), which is a bit more funky.)
In fact, it is rather weird for a scripting language to have an extra compilation step for classes. In case of sclang, I think the reason is mostly historic. By precompiling all classes sclang can build a “global method table” so that method call becomes a simply array lookup – instead of a more expensive hashtable lookup. Also, it does not need to walk up the inheritance chain. This has been an important optimization in the late 90s, but in 2023 computers are fast enough to deal with dictionary based method lookup.
Note that some method call optimizations can still be achieved without precompilation. See for example: Performance – Wren.
The simplest would be a “file-watch”, which would react to every change in the file and could trigger tests or something similar.
This does not really solve the problem that a recompilation of the class library destroys all interpreter state. I find this very annoying when developing my own classes.
*) Classes in JS are really syntactic sugar for prototypical inheritance
**) Lua does not really have a class system, but you can easily emulate with tables and metatables. (You can actually do the same in sclang with IdentityDictionary resp. Event)
