choice between using ins_id in either config/request time

[HSPm]

Hey - we've been using your vault plugin for years now and love it. We've been on v1.3.0 for quite some time and are now looking to to upgrade to v2 to stay up to date, but the breaking change where installation_id being moved to request time has us perplexed.
We have a lot of consumers of the github secrets engine (with multiple apps using different scopes) so having to update each consumer with the installation_id at request time will be a bit bothersome when they don't need to know about the github app installation id's.
Having the installation_id in the config step was perfect for us as we'd install the app once and it would pretty much be "set and forget" (is there a use case for reinstalling apps causing the installation_id to change?).
Is there any chance for both methods (config time & request time) to be supported here?

[isometry]

@HSPm : whilst the root plugin no longer supports config-time specification of the installation_id for the root <mount-path>/token endpoint, it is fully supported by the new permissionset system, through which you can specify a fixed installation_id (and also optionally configure subsets of the permissions or repositories associated with the GitHub App).

Example:

vault write github/permissionset/my-org installation_id=123456 # Installation ID for my-org
vault read github/token/my-org                                 # retrieve token for my-org

Whilst this requires that you append a path element to your client queries, the new system is extremely flexible and exposes far more power than the old one, whilst still supporting the full functionality. Does this cover your use-case?

[HSPm]

@isometry : the new permissionset system is great, but we are currently quite strict on repository scopes so I fear that it isn't a great fit for us.

Example:

path "gh/repos-rw/token" {
  capabilities = ["create", "update"]
  required_parameters = ["permissions", "repositories"]
  allowed_parameters = {
    "installation_id" = ["ins_id"]
    "org_name" = ["org_name"]
    "permissions" = [
      "actions=write"
    ]
    "repositories" = [
      "repo-1",
    ]
  }
}

But we've gone ahead and ahead and upgraded to @v2.3.0 and working our way through our migration process to the new version. Happy for this issue to get closed as not planned