And that I find a very fair criticism of the Networking TS
You're doing the same thing that the OP did, which is blaming Networking TS for not doing enough.
That would be a mischaracterisation. What I said is that there is an ideal design which lots of people would like if infinite development resources were available. The kind of resourcing which .NET had, for example. But we don't and didn't have that, so we don't get the stupid-simple API part. We stop short in the complex intermediate API, with the layers all smooshed together and indistinct. And not separated cleanly.
Please show me on the diagram why the availability of N and/or B are obstacles to implement SS?
Beast is an extreme example of a design wholly dependent on that of an external library. As ASIO changes, you'll have to spent a lot of time keeping up using resources which you'd prefer to invest elsewhere. This is a big reason why people don't choose Boost, and instead do poor man's local clones of Boost facilities. It guarantees no coupling on externally moving targets. For the same reason, it takes a lot of resources to build stupid simple high level APIs on top of shifting lower level APIs. I'm not sure it can be done by people unless full time employed to do so. And that's been historically very hard in C++, only a very few parts of the standard library were developed by people employed to solely do that and nothing else. So tldr, it's not an engineering problem, it's a resourcing problem, including the enormous resourcing requirement to build a consensus at WG21 and get it through plenary. Look at the vast resourcing Ranges or Coroutines sucked down, for example. High level stupid simple APIs are hideously expensive to standardise, even for a big multinational corporation like Microsoft (which largely sponsored both). Niall