Git resolver can no longer be used in remote pipeline

We are looking at ways to adapt and roll out Tekton Pipelines-As-Code in our organization. We are trying to create a central CI pipeline file where a single team takes responsability for the pipeline code and its tasks, and the other teams invoke it in their respective repos, by referecing it in their local pipelineRun files.

In this concept we want the pipelineRun to contain parameters and a reference to the central pipeline file, but the contents of the pipeline should be opaque, meaning that adding, updating or replacing tasks should be possible without involve updating the pipelineRun file in the teams git repo (or any resources in their namespace).

And this actually worked, until we upgraded to Red Hat OpenShift Pipelines Operator 1.10.3, from 1.9.2.

In each PipelineRun yaml file, one per repo, we have a PipelineRef referring to a Pipeline yaml file in common git repo. Each PipelineRun pass on the built-in parameters that PAC provides, plus some extra options needed by the pipeline. The pipeline file consists of a Pipeline with tasks that each use the git resolver, like this:

  tasks:
    - name: my-task
      params:
        - name: git_auth_secret
          value: "$(params.git_auth_secret)"        
      taskRef:
        resolver: git
        params:
          - name: org
            value: my-org
          - name: repo
            value: my-repo
          - name: revision
            value: master
          - name: pathInRepo
            value: task/my-task/1.0/my-task.yaml

Since the upgrade I get this error when the pipeline is triggered:

admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: must not set the field(s): spec.pipelineSpec.tasks[0].taskref.params, spec.pipelineSpec.tasks[0].taskref.resolver...

Is this an intended update to remove functionallity or is it a bug?

Reproduce the PipelineRun setup using a PipelineRef and nested git resolver shown in the issue, comparing operator versions 1.9.2 and 1.10.3. Start with the admission webhook validation for spec.pipelineSpec.tasks[0].taskref.params and taskref.resolver; done means establishing whether the behavior is intentional or a regression and recording the supported configuration or fix.