I'm shocked to see this up for review. The most recent pitch thread had a lot of critiques of the API that were unaddressed by the proposal authors. I was expecting some sort of closure there before seeing it go up for review. I also missed that this review went up at all, as it was not linked from the original pitch thread and got lost in the recent activity of forum posts. I only heard about it because I was talking with another developer who asked if I'd seen the review thread yet.
In reviewing this, I've gone to the proposal document linked above and tried to read it with an open mind. After thoroughly going through it, I've come to essentially the same conclusion:
This API should absolutely not be accepted in its current form.
The motivation is inadequate
This proposal aims to introduce an efficient, easy-to-use, less error-prone Progress Reporting API ——
ProgressReporter—— that is compatible with async/await style concurrency to Foundation.
NSProgress has a myriad of problems, especially centered around the complexity of its API and the performance of its implementation. So a superficial reading of the motivation might suggest that this pitch will be addressing those problems.
It does not. The proposed API is structurally identical to NSProgress: hierarchical reference types with complex composition, which seems a really odd choice in a world of async streams and value types. (I can't speak to the performance of the implementation; I sure hope it's better, but the pitch doesn't address that)
Nowhere in the motivation is there anything about actually addressing NSProgress's problems, which leads to the second point.
The solution is inadequate
I repeatedly brought up the point that having multiple consumers is a common scenario to account for when handling progress. Just the other day I came across another situation where this was once again evident, and could not come up with a way that this proposed API could be used to address that scenario. This need for multiple consumption was reiterated by other developers in the pitch thread and never addressed.
Nowhere in the pitch does it address why the strict hierarchical model is so desirable and (apparently) superior to other models. The authors seem to have decided a priori that this is the model they want and will not reconsider the base assumptions upon which the entire proposal is resting. That, in and of itself, should be utterly disqualifying for the entire pitch. How can we actually review something when feedback is ignored and challenges to fundamental assumptions are ignored?
I also disagree with the conclusions in the "Alternatives Considered" section that this type cannot live in the Standard Library. I believe that, if we were allowed to challenge the assumptions this pitch is built upon, we could come up with alternatives that would work over XPC connections, and could be extended to work with the Observation framework. It is an utter shame that our language primitives for performing work will still have no way to report progress of that work.
Summary
This is a far-less-capable replacement for NSProgress that doesn't address its actual shortcomings; its only benefits are some minor changes to type safety that make it a bit clearer how the hierarchy of progress should be constructed. But it does not add anything new that was not already possible with NSProgress and ends up removing many of its capabilities that power the workarounds other developers mentioned in the pitch thread.
Accepting this proposal means we will be left struggling with an inadequate progress reporting API that is overly-complicated and integrated at the wrong level of the language.