TPL Dataflow に関する前回のレポート以降，さらに詳細な情報が明らかになってきた。第１にあげられるのは，プロジェクトの目標が明確になったことだ。高レベルでの重点目標は，非同期プログラミング技術を活用した高性能なプロデューサ／コンシューマシナリオのサポートである。このシナリオは単独でも，TPL ライブラリが提供するタスクやクエリ，ループベース並列処理などと組み合わせても利用可能なものだ。
同じく重要なのは，TP Dataflow は何ではないか，という点である。Stephen Toub 氏は TP Dataflow について，Erlang のような完全なアクタ／エージェント形式の言語およびライブラリの直接的に置き換えるものではない，としている。TPL Dataflow はいわば積み木セットのようなものであって，関連するインフラストラクチャの設計が必要である点に変わりはないのだ。(そのような役割を目標にする Axum という別の研究プロジェクトが存在する。)
TPL Dataflow は一見すると，Reactive Extension とオーバラップしているようにも思われる。いずれもデータの移動に関連するものであるためだ。しかし Reactive Extension の重点が，複雑なプッシュベースのデータストリームを簡潔に記述する能力にあるのに対して，TPL Dataflow は，アクタやエージェントを構築するための基本的な構成要素であることをより重視して，どこでバッファリングを行うか，プロデューサをいつブロックするか，といったコントロール面を強調している。
４月版の TPL Dataflow CTP (Community Technology Preview) で提供される "データフローソースを observable (オブザーバブル，被監視側)，データフローターゲットを observer (オブザーバ，監視側) として公開する機能" を追加する直接統合は，これら２つのライブラリが互いに補完的な存在となる意味を持つものだ。その意図は，データフローと対応コードの間で，必要に応じてメッセージをシームレスに移動可能とすることにある。どちらか一方のみでもすべてを実現することは可能だが，双方がゼロベースから構築しなければならない部分をお互いの機能で補完し合うことができるのだ。
Stephen はさらに，TPL Dataflow 機能の多くに対して，非同期エージェントライブラリ (Asynchronous Agent Library) と呼ばれる，類似のネイティブフレームワークが存在することに言及している。命名規則の多少の差異を除けば，TPL Dataflow の方がアンマネージな実装に比べてよりリッチな API を提供している。データ受信が完了してシャットダウン可能なブロックを通知する組み込みサポートなどがその例だ。さらに TPL Dataflow には，サポート向上のために C# や VB といった言語レベルでの変更が実施されるという利点もある。これは C++ では実現不可能なことだ。
ユーザからのフィードバックによって，TPL Dataflow では，メッセージを処理する上で必要なオブジェクト割り当て数の削減が重点的に行われている。メモリ割り当ては.NET では非常に軽い処理だが，あまりにも過剰なオブジェクト確保は，最終的に非常に大きなガベージコレクションコストにも結びつく。アクティブタスクの再利用などの対策も，これに合わせて実施されている。最新の CTP では， DataflowMessage<T> クラスを DataflowMessageHeader 構造体に置き換えるなど，さらなる改良も施されている。もうひとつの改良点は，WriteOnceBlock<T> や BroadcastBlock<T> のクローニング関数をオプションとしたことで，不変メッセージ (immutable message) をより効果的に利用できるようになったことだ。
TPL Dataflow は Visual Studio Async CTP の一部としてダウンロード可能だ。リリース時期は確定していないが，VB 11 や C# 5 の新しい文法への依存度が高いことを考えると，それらと同時に発表されるのではないかと思われる。