For example, the log message for a slow query might look something like

Sun Apr  7 06:53:36 [conn42787593] query blahblah_production.posts query: { app_id: ObjectId('50d2a13fdf52405ff40ffcfa') } ntoreturn:0 ntoskip:0 nscanned:19869 index:TABLESCAN keyUpdates:0 numYields: 1 locks(micros) r:216562 nreturned:0 reslen:20 113ms

Having this info in the log would be useful because:

1) it distinguishes between incidents where a query was slow because it just used an index with poor selectivity, versus when it had no index at all.
2) it becomes easier to locate when the application is missing indexes without needing to rely on the invasive "--notablescan" option, which is often not acceptable in production environments.
3) the logs become greppable to find which indexes are involved in the most slow queries, which helps with optimization.
4) nscanned/nscannedobj is often misunderstood or ignored by users. This would help to clarify the relationship between nscanned/nscannedobj and the index that is chosen.