BG1, BG1: TotS, BG2, BG2: ToB, PST, IWD, IWD:HoW, IWD:TotL, IWD2

These files represent scripted actions. .bcs files are scripts attached to anything other than the player characters.  .bs files are scripts which drive a characters actions automatically (AI scripts) based on criteria in the environment.
Just as the files from which they are compiled, these script files make use of the concept of "triggers" and "responses". A trigger is a condition which causes a response with a certain probability. A response is one or more calls to functions they have exposed to the script. I believe this to be the difference between .bcs and .bs files. (They are assigned different resource types in the resource management code, too.)

The format will be given in a top-down sense: i.e. I will describe the formatting of top-level blocks, and then I will describe the contents of the blocks. The process will proceed recursively until the whole format is described. The top-level block is the script file.

First, a brief word on "function parameters". Both triggers and actions are essentially calls to functions inside the Infinity Engine. Triggers can take up to 7 arguments, and actions can take up to 10 arguments. There are three allowable forms of arguments: strings, integers, and objects. The different function calls are defined in TRIGGER.IDS and ACTION.IDS. There are also functions defined in SVTRIOBJ.IDS, which are a {sub|super} set of of the function calls defined in TRIGGER.IDS. They are probably used for {insert spiel here}. String arguments are simply quoted strings (i.e. ASCII strings delimited by the double quote character "). The format of these descriptions is given below, by way of an example (from BG's TRIGGER.IDS):

0x401D Specifics(O:Object*,I:Specifics*Specific)

The first thing on the line is the ID (in hex. IDs in scripts are typically in decimal). Next is the name of the function. Inside the parentheses, similarly to C/C++, is a comma-delimited list of argument type and argument name. The argument types are:
There is always a tag after the : and before the *. I believe the tag is used only for expository function -- i.e. simply an argument name to help discern the purpose. There is, however, one minor complication. Actions only have space for 2 string parameters. There are actions taking anywhere from 0 to 4 strings. Some of the actions which take strings (usually either 2 or 4 strings) actually concatenate the strings. In this case, it is always an "Area" and a "Name" parameter, (though the parameter names vary somewhat). The only surefire way to tell which is which is to hardcode the values of the actions which concatenate strings. When the strings are concatenated, the "Area" is always the first part of the resulting string, and always takes exactly 6 characters. It works, in most respects, just like a namespace qualifier in, for instance, C++. An aside: The functions which actually concatenate the strings are typically the ones which access "global variables", i.e. Global, SetGlobal, IncrementGlobal, et cetera. I am not certain, at present, how "action" type parameters are stored. This will require some investigation.
The final detail in the above example is the bit following the *. This occurs (I believe) only in integer arguments; the string following the asterisk is the name of an IDS file. The values in the IDS file are the only allowed values for that parameter; moreover, it is extremely probable that the parameter can be accessed using the symbolic names given in the IDS file, though this is merely speculation. Each trigger can use up to 2 (3?) integer arguments, up to 2 string arguments, and one object argument. These seven arguments are always specified in each trigger, even if they are not all used. If an argument is not used, it is assigned a dummy value. Finally, the arguments are used in order when they are listed in the scripts. For instance, two integer parameters always occupy the first two "integer parameter" slots in the trigger or action. A trigger has an additional "flags" field, in which, for instance, a bit is either set or cleared to indicate whether the trigger is to be negated or not. (i.e. whether the success of the trigger should return true or false).