What's not obvious about Option 1's flow is that the time between "200 OK" and "Bluesky servers index the record" is indeterminate. The 200 OK ends the transaction from the client's perspective, so now the client is going to struggle to show the user the actions they just took.

This article could just as well have been called "The politics of read-after-write consistency", which is honestly not something I've ever given any thought to.

There's nothing particularly specific to ATProto about this problem or its solutions. This could potentially affect any future evolutions of ActivityPub in just the same way.

In my own notes I've ended up with something similar to Paul's "Option 1", but with the "client" preemptively applying changes to its local view of the current state, on the assumption that the server is likely to index the new post and return it to the client as written; this will only lead to inconsistencies in the case where the server decides to do something different (such as rejecting the client's post because they've been banned from the group).