Expand on motivation

[dminor]

The motivation given here is mostly from the Async Iterator Helpers proposal. We'd like to see more examples, in particular, of how it would be used outside of iterator helpers.

Some questions that came up in our proposal review discussion:

• Why add a general interface instead of just making this part of iterator helpers?
• On the other hand, is this only being proposed to be part of the language to work well with iterator helpers? This seems like it could easily be a library, other than wanting it to work with the iterator helpers.

Fwiw, I think the now subsumed semaphore proposal did a better job on motivation.

[dminor]

Thinking about a little more, I'd also be interested in hearing why we're investigating in this direction and not adding an Atomics.Semaphore for example.

[Jamesernator]

• Why add a general interface instead of just making this part of iterator helpers?

Not a proposal author, but speaking generally having an interface here is useful as Semaphore by itself doesn't cover all possible concurrency strategies.

A pretty common example would be dynamic capacity, where some other part of the code measures throughput and changes the internal capacity of some semaphore-like "governor" until throughput is (approximately) maximized. (Honestly I feel most uses in promise based code would want this over a fixed size semaphore, but a widely applicable API shape here seems tricky to design).