Unexpected behavior with dynamic inputs when using null default/options

I have this input spec:

spec:
  inputs:
    workflow:
      type: string
      options:
        - deploy-env
        - destroy-env
      default: deploy-env
    deploy--environment-name:
      type: string
      rules:
        - if: $[[ inputs.workflow ]] == 'deploy-env'
    deploy--configuration-json:
      type: string
      rules:
        - if: $[[ inputs.workflow ]] == 'deploy-env'
          default: null
    destroy--environment-name:
      type: string
      rules:
        - if: $[[ inputs.workflow ]] == 'destroy-env'

In this sceneario, I have a workflow to choose from, which run different jobs.

Ideally, I wanted to use dynamic inputs to make the run-pipeline UI cleaner and avoid confusion when parsing arguments to specific flows.

Now this example that I specified actually looks great in the UI. Indeed inputs are filtered based on the workflow selected, and even marked as required if default: null isn't specified.

BUT, whenver configuring an option, the UI doesn't actually send it. You can see it both in the input preview and in the payload of the request. Gitlab sends it as an empty string no matter what is put in the field.

The only way it does work is if I add options and pick from there, but this doesn't allow for any free text which I require.

Im not sure if this feature is meant to be used this way, but it works perfectly for this use-case, up until this issue.