I believe this to be ready for another round of review. All changes I’ve applied are in a second commit that I intend to be squashed before merging. In summary, I’ve responded to all above feedback as noted in replies, but particularly:

1. Added a summary of all value types, dividing them into 3 instead of 2 categories: Atom, Container, Reference, such that the two reference types can be clearly distinguished.
2. Added an appendix on the meaning of Pass Invariant Equality to unravel some unclear prose
3. Provided a more clear explanation of the invariant preserved with separate Null and Undefined. It is narrow.
4. I’ve used Reference instead of Capability throughout
5. I’ve used Target instead of Remotable throughout

I’ve posted a subsequent commit that clarifies the various pass invariants and makes them explicit for every model type. I’ve also factored out the JSON invariants and referenced them for the two applicable caveats for Null and Float64. I also used the tentative aspirational example for marked targets in JavaScript, such that they can handle all deliveries, although this is not consistent with Endo’s implementation yet. For @erights consideration in particular.

I’ve adopted editorial recommendations, merged Identity and Equality into Equality, and removed the example for JavaScript targets ('to be proposed') since the current implementation of Endo CapTP does not reflect an ability to receive arbitrary deliveries and so doesn’t make a good example. When we have a way for a target to handle arbitrary deliveries (where the first argument is not a selector), I intend to update. That will also provide a suitable basis for the echo function we will need to test round-tripping of all deliverable messages.

Posted a fresh draft, now pending @tsyesika’s approval only.