The thing is that when there are coroutines they can work in random order, and they can end up but
BOOST_LOG_NAMED_SCOPE(...)
keeps scope's name on each stackframe being oblivious to the fact that those stackframes are not nested, so they can be destructed in any order, not to mention that it's not that hard to put on a scenario where the scope according to boost::log::named_scope is different from the actual one.
How to make boost:log compatible with boost::coroutine and boost::context ?
Named scopes in Boost.Log are maintained per-thread, using a thread-local storage, and consequently are incompatible with coroutines.
If you want a similar functionality with coroutines, you will have to implement a separate attribute that maintains a list of scopes in a coroutine-local storage. You can use Boost.Intrusive to implement the list itself. On Windows, you could use fiber-local storage to place the list. On other systems you will probably have to use the stack.
The above applies to stackful coroutines. Stack-less coroutines do not have a dedicated stack, so it is not possible to maintain a dedicated list of scopes that pertains to activity of a given coroutine.