我相信我们都会同意同步优于异步并不是一个好主意。TAP 模型极大地简化了使用 async/await 的异步调用，这就是正确的方法。
不幸的是，对于那些坚持使用旧技术的人来说，这不是一个选择。例如，.NET Framework 中的 Web 服务 (asmx) 不支持 TAP。在大型遗留解决方案中，维护重复的调用链（同步和异步）可能非常令人生畏和烦人。此外，即使您不知道，您也可能正在使用“同步而非异步”方法。许多提供同步 API 的库本质上在内部只是其异步 API 的包装器。例如 Rebus、RestSharp 等。
这是这篇文章/问题的主要目的。尽管我对 async/await 有相当的了解，但我不会假装我知道所有的极端情况（而且有很多）。所以，我想知道专家们对这个话题的看法。这种实施方式可能存在哪些缺点？
https://github.com/restsharp/RestSharp/blob/dev/src/RestSharp/AsyncHelpers.cs
与许多“同步优于异步”实现不同，它们通常只是启动一个新线程以避免可能的死锁Task.Run(async () => {await ...}).Result；此实现使用自定义同步上下文来避免死锁，同时保持在同一线程上。这提供了甚至访问的能力HttpContext.Current（对于 NETFX 应用程序）。
我已经在各种场景中尝试过这个助手，并且效果相当好。但是，我想进一步了解可能出错的地方。
那么，这有多错误呢？有哪些陷阱？