Understanding Lifecycle management with restricted keys (no delete)

I’m trying to understand what is happening when a file slated for deletion gets overwritten with a ‘hidden’ marker. Does one need to tell Kopia it must replace files with files with the ‘hidden’ tag rather than just deleting the existing file, or does it know intelligently it has a key which has no delete rights?

Second question revolves around Backblaze bucket settings when using restricted key access, and I would like to set the lifecycle to 7 days beyond the ‘hidden’ file replacement.
The choices are:

  1. Keep only the last version of the file (probably undesired, as the hidden file would then just remain indefinitely?)
  2. Keep prior version for x number of days (likewise, I think the ‘hidden’ file will just remain indefinitely here too?)
  3. Custom lifecycle rules: fileNamePrefix, daysFromUploadingToHiding, and daysFromHidingToDeleting

I think what I don’t understand is if a file becomes tagged with ‘hidden’, are there 2 versions with the same name, one with the tag and the previous without the tag, or is there only the one?

All happens on the cloud provider end without any kopia involvement. Kopia is not even aware that such provider functionality is enabled. As per docs:

Enabling restricted keys does not require any changes in your Kopia workflow, since Kopia does not need to change its behavior at all. The cost of this is that data will remain on the cloud provider for extra time before being deleted, potentially incurring additional storage charges.

You want to keep prior version for x number of days (your point 2). “Hidden” files will be deleted after x days. If I was you I would not enable it immediately for my most important backup:) Create some test data setup with short retention times and try for a week or two.