Well for 11, you might have to have a profiler trace with very particular filters running to catch such statements against your database.

For 12, I assume you mean recording say, an order and its detail lines (which would hopefully be in two separate tables!) - might be easier to piece it back together from the audit table as required.

For 13...  The new queues in SQL 2005 might be helpful as the records could be asynchronously processed to avoid blocking.  In SQL 2000, you could get really inefficient and use some COM calls to put things into MSMQ - yuk!   Or, make sure that if your app is querying from the audit tables, it does so with no locking.  Also have error checking so that if an insert fails it can be retried.

On that note - are you saying that the record may fail to be inserted due to blocking or due to primary key violations?

For the other points, yes, text fields would require that a join is done back to the original table, which might decrease performance, but if the auditing is worth it, then you pay the price.

To catch all tables as they are created (roughly), you could schedule a job to recreate all of the triggers, possibly taking some configuration info from a central config table so that certain tables/columns could be exempt from auditing.