Other than an occasional pull request (which is appreciated), I'm the only person working on the library and have to make the tough decisions that use my free time to the best advantage. The previous version supported multiple versions on multiple platforms,
the code had become more complex, adding async would add another dimension to the mix, and I saw an opportunity to act on the lessons I learned along the way. So, considering it's better to move forward than back, I went with async for this version. This makes
the development experience much easier for platforms that need it, like Windows Phone and Windows Store, and opens the library to the Xamarin platform, which targets even more devices like iPhone, iPad, Android phone & tablet, and Google Glass.

I know that some people will prefer to stay in their comfort zone, but this is a chance to embrace async while it's still relatively new. Besides offering more platform choices, existing developers have the benefit of using async technology with it's inherent
strengths for improving UI responsiveness and better performance and scalability on the server. As a network communications tool, LINQ to Twitter is ideal for async and is now the first LINQ provider outside of Microsoft's Entity Framework to offer inherent
async capability. In async scenarios, having frameworks and libraries that are inherently async make the development process so much easier. This is really more of an opportunity to move forward with something that will be supported in the future.

Well, asyncs are great and this is really an impressive job you and Microsoft did around their support, however it sounds a bit too early to fully cut off support of sync methods - Microsoft provides both options for their methods, some applications [console]
are just not capable of using async [for now] - or at least I did not find a good way to do it and that is why I started the thread....