FYI it was our bug that was causing stuck consumers, custom filter (0.8.6 based, so not using generic filtering support in hermes 0.8.7) was not releasing inflight semaphore on filtered out messages
you mentioned that response timeout is now configurable per subscription, in 0.8.8 - have you thought about making inflight (besides rate) configurable per subscription (with global/default max inflight)?
configuring rate and not inflight limit, especially not validating rate against inflight is potential source of misconfiguration - e.g. trying to increase rate, while too low inflight will be misleading, will not increase actual throughput limits
these are a bit separate concerns here. before we introduced backoff we had some problems with clients, who would be receiving same msgs again and again until rate control kicked in
so to mitigate this, we added backoff - msgs are now repeated in a certain time span, although rate control is still in hands of rate limiter
maybe it is time to rethink how backoff interleaves with rate control. we see that current rate control alg works very good for our clients, so it would be probably some kind of evolution to make backoff feel more natural to grasp
btw we used to have this simple algorithm you described (flat rate control + exponential backoff) in first versions of Hermes
but clients were not sure how to configure it to be safe. giving them single parameter (message ttl) which basically tells them for how long can the subscriber malfunction before discarding first message proved to be much better