If something written in sed is not really either a script nor a program, then what is something written in XSLT?

In principle, the two solve much the same problem: they are optimized for taking an input and relatively arbitrarily transforming it into some other (generally largely similar) output.

And a lot of my use of awk boils down to awk -F${sep} '{print $n}'. (For which in most situations I probably could use cut -d${sep} -f$n or something very similar to that. For some reason reaching for awk just happens more naturally for me.) Is that a script or a program? It almost certainly doesn't rise to the level of being copyrightable, or a lot of people will be in trouble. :-)

A script is a type of program. There's a bit of a distinction without a difference here, where the reality is more of a subset/superset relationship or at least a Venn diagram.

Emacs is interesting because (unlike vim, I think) it doesn't really have a way to interpret input line by line, not even in the `batch` mode. You cannot run

 emacs --batch < foobar.el

emacs just ignores its stdin in the batch mode, and always uses it for interactive command input otherwise. So the closest you can get is

 IFS='' ; emacs --batch --eval `cat foobar.el`

To me, that makes emacs feel more like a compiler of elisp, amd less like an interpreter.

The distinction I make between script and program is this:

the semantics of a script is contextual and dynamic

it depends on what executed earlier in the script.

on the other hand, the semantics of a program is context-free and lexical

you can understand the meaning of any part of the program, without having to execute any other part of the program.

I use this distinction, because by experience, we can have both situations using the same programming language. bash programs can be compiled. C programs can be interpreted. perl or lisp can be used to write either programs or scripts. (think perligata as the ultimate script).

Remember that the semantics of languages are independent of whether a given implementation of the language uses compilation and execution of compiled code, or interpretation (a lot of lisp implementations actually can do both!). Of course, when the language provides metalinguistic features, the risk of writing scripts is heightened. But even with the bare minimum, eg. redefinition of functions, can let you write scripts instead of programs.

Now, why scripts matter? Scripts are useful when you want to write some code that has to run in wildly different environments. Then the script must adapt to the environment it works in, and therefore we cannot predict the semantics of all the code, before running it, and establishing an interface with the actual running environment. On the other hand, when you have a run-time environment that is more precisely specified, then you can write programs.

Again, this is unrelated to the language. You can have bash programs, and you may have bash scripts.

Something is 'a script' when all it does is run the same commands you would have run at the interactive prompt.

So bash and edbrowse scripts, for instance, are scripts.

At least, that's what I want script to mean. I don't really use it that way - 'Perl scripts', for instance, are not automations of any user-facing program.