I think this is not a good argument against thread migration. While this whole TLS issue is certainly something that can lead to very subtile and hard find bugs, it's something that user level threads currently just can't deal with properly. As much as they look like std::thread, this is one of their limitations and usage of TLS should be highly discouraged.

Consider code like this:
void f()
{
    static thread_local int i = 0;
    std::cout << i++ << '\n';
}

boost::fiber f1(f);
boost::fiber f2(f);

This will print:
0
1

instead of what might be expected:
0
0

I suggest a pattern like boost.job proposes - on a logical processors a
worker-thread is pinned, running a pool of fibers (boost. job uses
some aspects of NUMA architectures). The jobs can be synchronized by
classes from boost.fiber.

I think NUMA awareness is something that is out of scope of Boost.Fiber and should therefor not be used as an argument against thread migration.

Especially since not all algorithms are memory bound. For compute bound problems, fiber migration across NUMA domain boundaries is not a big deal.

For memory bound problems, stealing inside of a NUMA domain can be benefitial.

All in all, it is not something the fiber library should decide but rather its user through the use of appropriate schedulers/executors.