I agree the described behavior exists and may cause problems. Have commands such as the one described been confirmed to be used by anyone? Moreover for the command used in the example there is a workaround 'pcs resource enable clusterfs{1..60} --wait=100' which apart from reducing number of pacemaker connections also greatly reduces load on pcs and pacemaker (cib would be read and written once instead of 60 times). Assigning low priority for now.

re [comment 2]:

> Have commands such as the one described been confirmed to be used by
> anyone?

Doubting otherwise unrestrained (documentation) usecases is not helpful.

Yes, this was an invented speed booster for rather massive set of
operations otherwise indeed preferred as an atomic change, allegedly
(much) faster than:

> Moreover for the command used in the example there is
> a workaround 'pcs resource enable clusterfs{1..60} --wait=100' which
> apart from reducing number of pacemaker connections also greatly
> reduces load on pcs and pacemaker (cib would be read and written once
> instead of 60 times).

If there are multiple ways to achieve the same with various trade-offs
(e.g. speed vs. load like here), people will always be creative, and
a robust program should compensate the cons whenever possible, which
is asked here.

Also note that it may be in the web UI's interest to asynchronously
-- based on synchronous pcs CLI equivalent wait under the hood -- inform
the user some operation has been finished, successfully or not, and
it's not hard to see that multiple operations can be triggered
concurrently, just as with the provided example, yielding the same
negative symptoms.

See also a possible syntax meant to decrease the amount of parallel
"waiting for pacemaker to settle" and hence also proactively prevent
people inventing their own wait-involved tricks: [bug 1620081]

I've been using this format:
pcs resource enable bobsrhel8{0..59} --wait=100
and it works beautifully (well, except for a myriad of unrelated
problems, especially with the Filesystem resource agent).

I haven't tried the original format for a long time.
I think this bz can probably be closed, as the original command is
similar to fork-bombing.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.