Your link is to doc for the old PLaneT package, so first I want to make sure you know that's out of date. Instead see the new package and its doc.

I see you've provided a put-acl function, but it's hard to figure out what a valid x-expression would be to use with it. The output from get-acl is pretty big, so do you have to replicate such an xexpr to use with put-acl?

I agree it's not convenient.

My doc links to the AWS doc explaining their XML for ACLs. My assumption was this would be the most comprehensive (and future-proof) way to support S3 ACLs -- just pass the XML back and forth as xexprs.

And in all honesty, it saved me from having to fully learn about S3 ACLs to the point where I could figure out a more Rackety abstraction in which to wrap them. I figured it would be worse if I attempted that but got it wrong, vs. leaving it up to users for whom ACLs are important.

It seems it would be very convenient for put/file to take a keyword argument like put/file b+p p #:acl "public-read".

I agree that would be more convenient.

My use of S3 is limited these days. Even when I used S3 more heavily, it was mostly buckets with the default access. So I don't have any hands-on with S3 ACLs. I also don't have an opinion about how to make the 80% case more convenient, while still allowing the 20% case. (I'm not even sure what the 80% case is, although I imagine it includes "public read".)

TL;DR: I think it would be wiser for something like this to be a pull request from someone for whom this is important?

@MicahElliott In case you still care, with put/bytes, you can supply a canned ACL as a 'x-amz-acl header. Maybe put/file should accept extra headers, too.
Pull request #53 adds an extra-headers argument to put-acl, so that it can be used like (put-acl <object> #f (hash 'x-amz-acl "public-read"))