When it comes to script-driven games (most modern 3D games), the way I understand it, the script IS the game, and it uses the engine as a tool, through the use of engine APIs, to implement the game itself. And in this sort of a design, modding is little more that modifying or extending these scripts. My question is, in designing these engine APIs for the script to use, are there any good existing examples or things to keep in mind? I know I could just look at the modding APIs available in existing games (and have done so), but each one is very specialized for that particular game. I'm looking for a more generic example, to point me in the right direction rather than just show how one particular game did it. More of an overview of engine features a script should have access to to be complete, from both a game and mod point of view. Any thoughts?

I think you answered your own question... each one is very specialised. The only standards I can think of for scripting are that you essentially need 2 things: accessors, to read the current state of the engine, and mutators to alter the state of the engine. Then you add as much as you can in terms of programmability, which allows you to arrange those accessors and mutators in terms of sequence, iteration, selection, expressions, and function calls (in roughly reverse order of importance, in my opinion).

Off the shelf scripting languages often give you a way to directly reflect your engine objects into classes (or functions into other functions) within the scripting language, which essentially covers the first 2 aspects, providing you expose the correct interface in the first place. Obviously the language itself then provides the programmability features.

Deciding what interface to expose would come about through a combination of common sense and formulating a few use cases. eg. Ask your designers what they would want to achieve, work out what accessors and mutators they need to do that, then provide appropriate implementations of them. The same principles apply here as would apply to general C++ class design when deciding what needs to be public and what can be private. You make a judgement that allows the outside world to pass and receive messages from the object while allowing it to manage its own internals.