Advanced captchas like T158909, T87598 or T34695 need to be able to fall back to other captchas (T158909 because it can only detect humans, not bots; T87598 and T34695 because they keep from a dynamic pool of known-good answers which might get depleted). It would be nice to handle that at the configuration level instead of making it the captcha implementation's responsibility to handle falling back.
A nice way to handle it on top of T177133: Turn ConfirmEdit captcha implementations into a family of services would be to allow captchas to respond with OK/FAIL/PASS and have a "manager" implementation of the captcha service which takes a list of other services and calls them in order until one returns a non-PASS response. (In practice it should be a bit more complex than that, probably remembering the fallback level between requests via the session.)
Maybe even captcha throttling could be spun out into a separate "captcha" implementation which always returns PASS unless the throttle limit is hit. That would be one less responsibility the individual captcha implementations would have to care about. That would also allow more flexibility for things like T42496.