I too struggle with the limitation of one subscription per “request response” type trigger. I haven’t delved into this with the product team to understand why the limit is one, but that is what we the users have to work with today. I suppose part of the challenge of allowing multiple subscriptions is how to deal with multiple subscribers that may respond back to the service with a decision on a particular access request. It could be as simple as first come, first serve, but I don’t know enough about the implementation to know if there are edge cases to be concerned about. Regardless, this just pushes the complexity onto the user implementation, which isn’t ideal. As you stated, the current way to handle this is to have a primary workflow with several comparison operators to determine how to handle each access request. This primary workflow could invoke child workflows to do the actual processing so that there is not a mega workflow doing it all.
It is worth noting that the request response triggers are unique in that they actually interrupt the approval chain while waiting for a response, whereas a fire and forget would not interrupt the approval chain. This is valuable because it allows an automation to preemptively deny a request before it reaches a human approver, reducing the amount of approvals a human might have to deal with. A fire and forget version of this trigger would still allow you to cancel the access request in your automation, but the approval process would still be initiated and at least one human will have received a notification to approve/deny the request.
Would your concerns be reduced if the request response triggers could accept 50 subscriptions like the fire and forget triggers?