One may wonder why not to allow the use of 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 the slowdown significantly greater because of the need to allocate memory and copy the string (not to mention that 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) would 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 reduced dynamic memory usage and provided enough flexibility for common needs.