Releasing lock ignores metadata

I am trying to do an atomic update of metadata, and the update parameter does not help because I have to create or modify the metadata outside of the lock. Doing so would potentially cause the step to overwrite an update that happens after I get the lock to be able to modify it.

What I would like to do is this:

      - do:
          - put: environment_pool
            params:
              claim: environment-1

          - get: environment-1
            resource: environment_pool

          - task: update_metadata
            file: shared_tasks/update-metadata.yml
            input_mapping:
              environment: environment-1
              project_repo: my_application_repo
              build_version: my_application_version
            output_mapping:
              environment_out: environment_out
            params:
              APPLICATION_NAME: my_application

        ensure:
          put: environment_pool
          params:
            # This should(?) commit the metadata from environment_out
            release: environment_out

It seems like it would be a simple change to have UnclaimLock() take inDir as a parameter and do the mv command from there. However, I wonder if there are reasons for not doing it this way. Is there any other workaround I might use?

Start by reading the UnclaimLock() implementation and the lock-release flow. Trace how the shown get/task/ensure sequence handles environment_out and metadata, then determine whether release can commit it without overwriting a later update. Done means the atomic metadata behavior and any supported workaround are documented by tests or clearly resolved.