Thank you @grynspan! This is a useful enhancement to confirmation() and offers a conceptual analogue to some of XCTest's XCTestExpectation APIs.
Since it was originally posted, the proposal and its implementation PR have evolved slightly which is worth calling out. One piece of feedback I gave was that passing a RangeExpression literal which lacks a lower bound such as ...10 could lead to surprising behavior because such a range includes 0, meaning that a confirmation() would succeed even if never confirmed. Jonathan amended the feature to require explicit lower bounds for this reason — see Ranges without lower bounds in the proposal for more details.
One question from this pitch thread was whether this API might allow tests to become under-specified and lead to flaky behavior. While this is possible, we think there are valid reasons to need to specify a min and/or max number of expected confirmations, and in particular, the ability to specify "at least N" (without any upper bound) can be quite useful. Analogous functionality in XCTest (expectedFulfillmentCount) has existed for many years and we have not observed that to be problematic.
This proposal is accepted. Thank you to everyone who gave feedback!