Found some similar issues and PRs in other projects.

• multipart upload id is converted by url encode s3fs-fuse/s3fs-fuse#2097
• Error when coping data to Cloudflare R2 duckdb/duckdb#5685
• Support copy_if_not_exists for Cloudflare R2 (S3 API)  apache/arrow-rs#4190
• Add support for multipart uploads to the R2 bindings cloudflare/workers-rs#260

Seems like this is an issue with Cloudflare not with distribution.

It is not an issue with R2. It appears that other implemented it compatible with other S3 providers including AWS.

URL encoding the multipart upload ID in the query parameter. This is either caused by R2 having differently structured IDs, or some difference in handling non-urlencoded query parameters.

These two statements seem contradictory to me:

It is not an issue with R2

This is either caused by R2 having differently structured IDs...

Note: I should clarify that I am not trying to imply that R2 is broken in any way - I'm just saying that distribution does not provide support for R2 storage backend and the proclaimed S3<->R2 compatibility does not seem to be quite there. I admit my saying "Seems like this is an issue with Cloudflare not with distribution" came out the wrong way.

Got it.
What is important to me is that if I resolve the issue and make the Docker distribution R2 compatible, will the PR be accepted upstream.

Please do go ahead and open a PR, indeed. I can't give you guarantees if the PR will be accepted but I can tell you it'll certainly be reviewed and considered. With the PR at least we'll have something concrete to discuss :-)

@Vad1mo can you point to the exact line/file where this URL encoding is (not) taking place?

@ichernev no idea, I was searching for PRs on GH with same/related issues, I didn't have time to look in into docker distribution. Are you in the same boat?

@Vad1mo well, yes. I was planning on using R2 (due to the "compatibility" with S3) but I guess it is still an open issue. I might have some time to debug the root cause of this in the coming weeks. If you figure out what the issue is (even without a patch), I can help with moving this forward.

@tpoxa is working on a fix from our side

I incremented the chunksize per this suggestion and it seems to make the problem go away in my tests.

storage:
  s3:
    chunksize: 104857600 # 100MiB

Following the thread, if I am not mistaken, the problem seems to be caused by the combining small part feature? Perhaps, this change impacts the logic of combining small parts?