Change:
A member of the group creates a Commit message and the corresponding Welcome message at the same time, by taking the following steps: <del> Construct an initial Commit object with "updates", "removes", "adds", and "ignored" fields populated from Proposals received during the current epoch, and an empty "path" field. </del> <ins> Construct an initial Commit object with "updates", "removes", and "adds" fields populated from Proposals received during the current epoch, and an empty "path" field. </ins> Generate a provisional GroupContext object by applying the proposals referenced in the initial Commit object in the order

Discussion:
Ignored proposals don't make sense to me. How can they possibly add value? Also, re-structured section on Commits some. !
I'm afraid the flow chart might not quite be that simple. It is possible for there to be proposals that (1) don't appear in the Commit and (2) don't need to be re-sent. The simplest case is when a member sends two Update messages within an epoch. On the one hand, there's no practical need for them both to be included in the Commit, since one will overwrite the other. On the other hand, at the same time, the new member shouldn't re-send the stale Update. The idea of the array was to provide a slot for these to be included in the Commit, but without the need for recipients to act on them.
On a separate note, it would be helpful if you could base your different PRs on master, to make the specific changes clearer.
In that specific example, the member is aware of all the Updates they've sent and can know to only expect one to be included. In fact, the member can try to enforce a lot of things: Re-send if no Update was included. Re-send if the included Update isn't "recent enough." Re-send if the included Update isn't the most recent. The member's own sense of what should/shouldn't be included is what matters here, not the comitter's.
I can agree that the difference between "Proposal got dropped somewhere in the ether" and "Proposal was consciously ignored by the Committer" is not really salient. I'll post to the list to see if anyone else objects.
NAME raised some concerns with this on the mailing list. I proposed a compromise there, of the form: Specify that if a Committer receives two Updates proposals for the same leaf in the same epoch, then it MUST commit the latest one it received. State explicitly that the only Proposals that may be omitted from a Commit are: Invalid proposals (e.g., because of a bad signature, parsing error, reference to a non-existent leaf) Proposals whose effect on the tree is overwritten by another proposal, which at this point includes only: Updates for a leaf prior to the latest Update received by the committer Updates for a leaf for which there is a Remove in the epoch
NAME - How does that strike you?

Isn't that what's currently in the PR? The only difference is "SHOULD prefer the most recent Update" because it's not enforceable anyway
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .