The most interesting design detail in Nebula1 (the close connection between C++ classes and '''Tcl''') was also its biggest 
problem in Project Nomads.

A lot of Project Nomads consisted of Tcl scripts which directly called into C++ class interfaces exposed to Tcl. 
This was extremely flexible, but also put too much power into the hands of gameplay scripters which came up with hair-raising 
workarounds for missing features in the C++ code heh.

Another design wart was that we also closely integrated Tcl into the asset pipeline (e.g. you could attach small 
Tcl 'scriptlets' directly to Maya 3D objects which then would be evaluated during the asset export). This means we had 
to carry a small Tcl interpreter in the Maya plugin all the way to the end even though the actual engine long had 
dropped any support for Tcl scripting.

Project Nomads scripting left such a deep scar that I removed all scripting features in Nebula3 (which the gscept/nebula 
version is based off, although I see there is some Python support under addons/scripting), and I remain a big sceptic when 
it comes to integrating 'scripting languages' into game engines. A probably too extremist pov.

TL;DR: don't expose your low level engine APIs to scripting, and don't use the same scripting API for persistency and/or 
asset pipeline file formats, it will inevitably end in tears ;)