I was writing a spec for how to handle replies in our project, and once I finished it, I realized it might be useful to others as well. There’s nothing fundamentally new here (as far as I know), it builds on existing specs, but brings them together into a single, coherent set of instructions with examples. It also makes certain logic and attributes mandatory (MUST) to reduce ambiguity and limit overly flexible interpretations 
Please let me know if you notice any issues. Thanks!
Replies are delivered only to the replier’s followers.
Other authorized participants (e.g.followers of the original author) do not see all replies.
The conversation splits into inconsistent partial views.
FEP-1b12 solves this for Groups by introducing a central routing actor, but there is no equivalent for ad-hoc, user-owned conversations.
The equivalent is FEP-171b: Conversation Containers. It is in fact very similar to the proposed mechanism, with two key differences:
- FEP-171b uses wrapper activities instead of forwarding
- Your FEP introduces context addressing
I think the "no equivalent" statement should be removed. It would also be nice to provide a list of differences between your proposal, FEP-1b12 and FEP-171b.
SHOULD include the Context Object URI in
toorcc
This might cause issues because ActivityPub requires servers to expand collections:
If a recipient is a
CollectionorOrderedCollection, then the server MUST dereference the collection (with the user's credentials) and discover inboxes for each item in the collection.