Multi-tenant Policy caveat with `allowed_parameters`

Vault
1

I’m looking into designing policies for a [non Vault Enterprise] multitenancy use case were i’d like to allow tenants to create Vault policies and auth roles for use in their applications.
For isolating tenants, i’d need to limit each tenants role permissions and only allow each tenant to manage and use roles and policies that are prefixed with their unique tenant name.
Based on the fine grained policy docs and other forum posts, something along these lines should be possible:

// Allow `tenant-name` to CRUD Vault policies and auth roles
path "/auth/aws/role/tenant-name/*" {
  capabilities = ["create", "update", "list", "delete"]
  allowed_parameters = {
    "role" = ["tenant-name/*"] // Create tenant role
    "auth_type" = ["iam"]
    "token_policies" = ["common", "tenant-name-*"]
    "*" = [] // any other parameters may be created with any value
  }
}

My concern at the moment is that the fine grained param docs mention that
there’s a caveat in allowed/denied_parameters that globbing may result in surprising or unexpected behavior.

This is referring to allowed_parameters policy rules for parameters
like token_policies which are multi value and implies that, with the above policy,
the tenant would still be able to attach any policy to the role by using comma delimited values (ex: “common,tenant-name-app1,super_dangerous_policy”).

So, is this implementation strategy viable and/or is there any workaround without Sentintel ?