I think the best colloquial definition at this point is "a higher-level language that delegates to lower-level code for core logic". Usually that higher-level language is interpreted and dynamic, but it doesn't have to be. I read a post once that suggested using Haskell as a "scripting language" for Rust.
This definition is most precisely used in games, where the dichotomy is particularly common due to their high requirements for both performance and creative expressivity. But it also nicely encompasses bash scripts delegating to C utilities, JavaScript delegating to the web browser, and Python delegating to NumPy. It's also generally the goal with embedded languages like the one in the OP.
Thanks, yes that's very helpful. In my experience (scientific and web backend programming, no games and no industry compiled) there's a large number of people who are not aware of this definition of scripting. For them, a "script" is a program written in a procedural style that runs and does some stuff and exits.
So, for example, web backend python programmers might "write a script to run on prod to fix the messed up data", but they would not refer to their flask/django HTTP handler code as scripts (whether they defer to numpy or anything else).
In research labs, scripts (sensu me) are often the only category of code that is written. They fit the definition you gave in that they probably delegate to things, and the one I gave in that they are typically procedural and linear.
This definition is most precisely used in games, where the dichotomy is particularly common due to their high requirements for both performance and creative expressivity. But it also nicely encompasses bash scripts delegating to C utilities, JavaScript delegating to the web browser, and Python delegating to NumPy. It's also generally the goal with embedded languages like the one in the OP.