The sproc only has access to its value of @@NestLevel; there is no "external" or other context to compare it to so it doesn't know about any differential (magnitude of the jumps). With the exception of using some form of table MSSQL goes out of its way to prevent the user from maintaining any context info across sproc/function calls and batch transitions.

Even if dbo.DBPrint could store some persistent level-related context it still wouldn't solve my problem as there may be intervening call levels that don't use dbo.DBPrint so it wouldn't have a chance to "know" and "remember" those.

The real solution is for sp_ExecuteSQL to handle @@NestLevel logically (or at least explain why it apparently doesn't in BOL!).

At this point I've grudgingly settled for there being a two-level indent jump at some points in the output stream (where something has used sp_ExecuteSQL to continue the call chain).