The approaches are similar and both the Task Parallel Library and Async Workflows were originally developed mostly independently and for different reasons and have different audiences. There are certain things that TPL cannot do that F# async workflows
can such as multiple downloads without any blocking threads. Promises block at the .Value property call.
As for unifying TPL and Async Workflows remain to be seen and it may happen. I can't speak for the F# team on this one although we do like to talk often enough.
In a way the Maybe is like the Nullable type, but it's a bit more than that since it's a unifying type which says what has a value and what does not for both reference types and value types.
Your thoughts around pure actions and purity is interesting, but since C# is a first class object oriented language with many imperative features, it's hard to bolt on such concepts as immutability (deep and/or shallow), purity, side effect free functions and
so forth. With the utilization of Code Contracts for .NET 4.0, we could get part of the way there, but for the most part, any checks for purity are mostly just suggestions and not enforced. Instead, concepts such as these belong in its own language, for
which F# is well suited on the .NET platform. Although there are projects to bring Haskell to interoperate with .NET
Well, there are two ways about handling failures. There is the use of the Maybe Monad which states that you have Just the value or Nothing at all. But sometimes, we want to be a bit more explicit than that. For example, we may want an error message,
or in the case of F#, the actual exception itself, or the return value from the function. If you use the Async.Catch function from the F# Async Workflows, it is exactly that which either returns the computed value or the exception should one occur.