Vector Tiles on osm.org ( https://github.com/openstreetmap/operations/issues/214 ) が私の経験上、けっこう興味深かったので、メモを残します。あまり正確ではないメモだと思いますので、詳しくは原典に当たってください。

経緯など

esri 実装に関する情報

slibby のコメントによれば、esri の OSM ベクトルタイル実装は、OSM の minutely changes を PostGIS データベースに同期していくという、「非常に一般的なアプローチ」を用いた後、後段に ArcGIS Pro を配置し、「nearly-mapbox-spec」なベクトルタイルをパブシッリュしているとのことです。
同コメントによれば、PostGIS の同期の時間粒度が分であるのに対し、ベクトルタイルの同期の時間粒度は低いのが現状で、時間粒度を高めていくことを目標としているとのことです。

osm.org に早期にベクトルタイルを配備することについて合意しました。
画像タイルである osm-carto を置き換えません。
ベクトルタイルから画像タイルを作ることは、後ほど古い環境の救済手段として考えることはあり得るとしても、少なくとも当初は考えません。ベクトルタイルをクライアントに送信するシナリオを扱います。
ベクトルタイルのサイズには留意しつつ、できるだけ多くの OSM ジオメトリやタグを提供することを目指します。
おそらく開発の後期になると思うが、狭帯域シナリオ向けに「軽い」スキーマを提供することも検討します。
経験者の中には、サーバとして Tegola を勧める者もいました。
レンダラについては、強い意見はありませんでした。
OSM のタイル利用アプローチ（重い利用を禁止し、無保証である）を執行するために、ベクトルタイルスタックが有効かもしれません。
osm.org で簡単なスタイルエディタを提供したいという話も。
ハードウェアは問題ありません。osm-carto 用のサーバの一台を振り向けるでしょう。

1., 2., 3. は基礎的かつ重要な合意で、ここに合意を得られらのはよかったですね。
4., 5. に関して、性能の観点から、サイズコントロールはとても重要です。国連ベクトルタイルツールキットでは、mbq でサイズコントロールの指標を持っています。4. と 5. のどちらを優先するかは、戦術ですが、私だったら軽い方を先に作って重い方を増槽版として出すことを考えると思います。
6. は参考になりました。Tegola、覚えときましょう。
7. はこれから建設的に揉めることになると思いますね。良い議論がされることを願っています。私は今のところ、tippecanoe に自分の駒を置いています。
8. は、やや、欲張りかもしれませんね。
9. と 10. は正しいセンスだと感じます。

BoF の結果は順当で、安心できるものです。この GitHub のスレッドを読んでいると、話が脱線してしまうのではないかとハラハラしましたが。
ベクトルタイルからの画像レンダリングの話に流れないようにしたのは良い捌きだと思いました。
クライアントサイドライブラリについて、Leaflet にこだわるのはやめたほうがよいと思います。Mapbox GL JS を用いるか、自己規制を破って自ら実装するしか技術的な答えはないはず。後者については、政策・能力の両面で無理であろうから、前者をとるしかないでしょう。
サーバ側の議論については、参考になりました。Tegola、覚えときましょう。
osm.org がベクトルタイルを提供する目的については、合意された整理があるという情報は得られませんでした。目的を整理することは大事だと思います。引き続き、ウォッチしたいです。