Hi Sean,
I see, yes this could be a problem. I think in order to see if there’s a feasible solution we need to look at a real use case…
For example, A policy can control multiple facets:
- Quota
- Rate limit
- Access control (API & Version)
I’m assuming you would want to have a class of policies that sets rate limits and then another class of policies that sets access control. Or, more complex: Class 1: Quotas, Class 2: Rate Limit and Class 3: Access Control.
Then when a token appears and it’s metadata is read, we detect a list of policies instead of a single policy, with each policy selectively enforcing a class, in turn, composing the access rules for the token itself.
In terms of implementation, there would need to be some changes, we would need to add a new field to the token data:
Then modify the policy object to have a few bools:
...
PolicyIsPartitioned bool
Partitions: struct {
Quota bool
RateLimit bool
Acl bool
}
...
We can then have the policy enforcement method only apply the partitions that are enabled in the policy, that way you could have combinatorial policies (and they can be in any order).
So yes, totally doable, and actually a good idea because it increases the effectiveness of policies, since you can then create policies that are either all-in-ones, or are combinatorial.
Getting this into the gateway is pretty straightforward, adding it to the dashboard and portal will take a bit longer though 
I’ll put it on the roadmap, because even in a partial implementation it could be very valuable.