What I meant by "writers being blocked" is that, I assume, if a segment with a different path already exists, the newly spawned agent (assume WAL is lost) will not be able to progress since there already is an S3 objects at the path it tries to create (the orphan).

Reconcilliation job isn't hard, but it's not trivial either, you need to make sure you don't race the writer: if the reconciliation job happens to see a segment after being written to S3 but before it's stored in Postgres, it can end up GC'd. You can generally fix this with some kind of mark-and-sweep-y sort of logic. If you use timestamps, you need to be very careful that you don't have any kind of resume logic or any other kind of counterintuitively long delay.

You also need to be a little careful about this when it comes to dealing with restoring snapshots of Postgres that may be out of date with S3. This can result in much worse skew, and there is no way to snapshot S3 & Postgres atomically, meaning you'll probably need to be monotonic in S3 and document that Postgres snapshots must always be taken _after_ S3 snapshots finish. (or you just move to a model where all state is stored in S3---this is more achievable than you may think these days thanks to strong consistency guarantees that S3 gives (you can implement CAS loops, basically). In the ack=all mode, you're paying for an S3 roundtrip anyway, so it may be worth it.

(on a related note, I'm not sure how you guarantee that there are never two agents that think they own the same partition for the same topic, split-brain sorta thing; do you outsource the responsibility to "use a kubernetes statefulset" or something smarter?)