One may wonder why not to allow to use arbitrary strings as named scope names. The answer is simple: for performance and safety reasons. Named scope support functionality has one significant difference from other attribute-related features of the library. The scope stack is maintained even when no logging is done, so if a function foo has a BOOST_LOG_FUNCTION() statement in its body, it is always a slowdown. Allowing the scope name to be an arbitrary string would make slowdown significantly greater because of the need to dynamically allocate memory and copy the string (not to say there would be a need to previously format it, which also takes its toll).

Dynamic memory allocation also introduces exception safety issues: the BOOST_LOG_FUNCTION() statement (and alikes) will become a potential source of exception. These issues would complicate user's code if he wants to solve memory allocation problems gracefully.

One possible alternative solution would be pooling pre-formatted and pre-allocated scope names somewhere but this would surely degrade performance even more and introduce the problem of detecting when to update or free pooled strings.

Therefore restricting to string literals seemed to be the optimal decision, which minimized dynamic memory usage and provided enough flexibility for common needs.