Rx Update: Async support, IAsyncEnumerable and more with Jeff and Wes

This is very interesting conceptually, (I know it's a big ask) but is there a chance of creating a feature builder .vsix detailing examples and scenarios on how to use this? Seeing it in practice cements it into my daily mental problem solving tools, where as right now it is "Rx, that sounds nifty to play with sometime."

Something like what Karl did with MVVM training would be perfect.(http://karlshifflett.wordpress.com/2010/11/07/in-the-box-ndash-mvvm-training/)

Okay one thing (++) here is super awesome. And that is Count -> Task<int>! You can timeout on and cancel a count!

Interesting. Because the continuation monad is the mother of all monads, and because async is almost continuations, you can *almost* do LINQ to Async!
If you have an expression await x, if the compiler transformed that to x.Await(continuation), with continuation a callable object that calls the continuation, then we could implement Await as just calling SelectMany, and it would work automatically for IObseravable and all other things that support SelectMany. Then you could do things like:
async IObservable<int> Foo(IObservable<int> a, IObservable<int> b){
   int ai = await a;
   int bi = await b;
   return ai + bi;
}
And it would be the same as:
IObservable<int> Foo(IObservable<int> a, IObservable<int> b){
  return a.SelectMany(ai => b.SelectMany(bi => ai+bi));
}
Of course it would work for arbitrary things that support SelectMany.
Problem is, the continuation is one shot, so SelectMany can only call it once? :(
This is a pity, because this would have been a powerful feature: async as syntactic sugar over monads (or LINQ).

The "Task vs IObservable" is like the "Nullable vs IEnumerable" (when we have Enumerable.Empty).

I am one of the people who, at first, believed that awaiting an observable should wait on the next item, not thinking there was any other possibility.  Of course, once I saw there were the possibilities of awaiting the entire collection as well as awaiting the final value, I see it makes sense to default to the entire collection and provide methods for the other options.  However, I don't really agree with the names used for the methods.

The method ToTask doesn't really explain what it's doing.  It converts an IObservable to a Task type, but what exactly does that mean?  Nobody will know without first looking up the documentation, and hopefully attempt to commit it to memory (maybe this is Microsoft's "evil" attempt to force people to actually read the documentation?).  ToTaskLast is a bit more explanatory, but still seems confusing as to it's purpose.

In the example of ToTask, what is really trying to be done is to get the next available value of the observable, while ToTaskLast is to the last available value.  Much better names for these methods would be GetNext and GetLast.  Of course, GetNext and GetLast would read as returning the actual values and thus blocking until available.  The awaitable methods would thus best be called GetNextAsync and GetLastAsync.