Хех, сегодня копнул еще глубже в историю CLR-over-fibers и, кажется,

достиг ее дна.
Начиналось все с наличия [Obsolete] на AppDomain.GetCurrentThreadId() и методов Thread.BeginThreadAffinity()/Thread.EndThreadAffinity() - мол не ориентируйтесь на идентификатор нативного потока, управляемый поток может крутиться поверх fibers и перескакивать с одного потока на другой. И этот [Obsolete] можно игнорировать в случае UI-потока, так как он всегда STA и привязан к одному нативному потоку всегда.
Но тут пришел @EgorBo и сообщил, что CLR и CoreCLR нифига такого не поддерживают и не планируют поддерживать, и там всегда управляемый поток всегда привязан к нативному (с оговоркой, пока не был позван Start - управляемый поток не привязан ни к какому потоку). Значит, думаю, это специфичная фича для SQLCLR (CLR которая крутится внутри SqlServer) и за пределами SqlServer можно об этом сценарии не думать.
Однако, сегодня выясняю, что хоть SqlServer и поддерживает fiber mode (называемый lightweight pooling) - но в таком режиме не поддерживается использование SQLCLR! Думаю - может сломали в SqlServer 2012, который переехал c CLR 2.0 на CLR 4.0? Но нет, в 2008 и 2008R2 такая же история!
Полез копать документацию - везде фигурирует в качестве примера SqlServer 2005, мол в нем fiber mode возможен. Полез копать глубже - нет! В SqlServer 2005 точно такая же история.
Оказалось, что в первых версиях CLR предполагалось, что управляемый поток всегда привязан к нативному, но при разработке CLR 2.0 специально для SqlServer 2005 предусмотрели режим работы CLR в fiber mode, и завезли кучу абстракций в корлиб (Thread.BeginThreadAffinity etc) и в рантайм (ICLRTask, IHostTask + соответствующие менеджеры). На базе этих абстракций написали документацию, книги, завели соответствующие code analysis rules... но фичу эту так никогда и не выкатили! Потому что криво работает, особенно в сценарии долгоживущего процесса (коим SqlServer и является). И единственный способ такой сценарий посмотреть - это взять и руками допилить SSCLI 2.0 что б вернуть поддержку такого режима.
И вот ради такого никогда не поддерживаемого сценария у нас есть фактически no-op API в корлибе, и бесполезный пятнадцатилетний [Obsolete] на AppDomain.GetCurrentThreadId() (и видимо из-за него забили на нормальный порт этого метода на NetCore - в NetFramework возвращался идентификатор текущего нативного потока, в NetCore вместо OsThread.GetCurrentThreadId()/PlatformNotSupportedException возвращается Environment.CurrentManagedThreadId. Хотя, это может быть просто ленивый дизайн "что б хоть что-то было", как в ситуации с CultureInfo.ListSeparator)

Возникает вопрос, раз фича (fiber mode) по-сути так и не использовалась, то зачем поддерживать эту нигде не используемую и добавляющую сложность абстракцию?

Интересно, а Xbox, Silverlight или WinPhone могли использовать?

Видимо к моменту создания ReleaseCandidate CLR 2.0 уже было слишком дорого выпиливать сделанный код из основного бранча (и там был явно не git, а SourceDepot скорее), а потом оставили API для поддержки обратной совместимости

SourceSafe?

Не пора ли внести предложение в .нет выпилить и отправить на покой?

Не, этот ужас вроде только купили, что б вместе с VisualStudio 6.0 поставлять, а внутри не использовали

А фиг его знает, если про SQLCLR в 2005 еще можно что-то нагуглить, то эти таргеты и детали реализации рантайма инфы крайне мало. Не помню, был ли в API WinPhone вообще System.Thread или нет

Просто у кого-то хорошие детективные навыки, ну и результат вообще на статью годится как по мне

На ишшуй в репе кора, чтобы кто нить убрал ненужное в коре

Я могу только предлагать самому удалить код

Удалить можно, но это значительное изменение