Not really simplification if you go from <300 characters to > 500 characters. Also stuff like “The Amnesiac that adds the new Segments decide the order of insertion.” potentially gives extra power to admins which should be avoided.

Also stuff like “and so on” and “indexes must be updated” aren’t entirely clear

I said this on the previous post but I’ll resummarize:

1) After a Segment is removed, the updating admin can pick any new segment order as long as it results in an Ordered List

2) “And so on” doesn’t really say what to do with any of the additional Segment. How about if you replaced “The first new Segment” with “each new Segment” and took out “and so on”?

@Clucky and @ayesdeeef: I updated the proposal to be more clear :)

@Clucky: note that I defined Ordered List and said “Indexes must be updated, so the Segments returns to be an Ordered List”

@ayesdeeef: I defined Segments as an Ordered List, when the first Segment has Index 1 and so on. So it’s the order that defines the Index, not the contrary. The admin must simply update the Indexes accordingly to the order, it’s not stated it can reorder the Segments :)

Clarifying what happens to wagers that use deleted segments is good, but this is adding redundancies (we know we’re allowed to add and remove Segments, because we’re playing Nomic: the same is true of everything) and a potentially unresolvable situation. “The Amnesiac that proposed the new Segments decide the order of insertion.” is a problem if an admin is enacting a proposal which failed to specify that order: they have to ask the proposer to decide the order of insertion, and the proposer might be offline.

I think Ayesdeeef is right that “the Indexes must be updated, so the Segments returns to be an Ordered List” would allow the segments to be updated into any order. Which may or may not matter (it doesn’t right now), but it’s less clear than the current system of closing up the gaps.

This also looks like it’s removing the “If two Segments have the same Index” check without any equivalent replacement?

(To be honest I’d be tempted to repeal Indexes entirely and define the Spin roll in terms of table position, and say that table positions are fixed, with new Segments being added to the bottom.)

@Kevan:
“I’d be tempted to repeal Indexes entirely and define the Spin roll in terms of table position, and say that table positions are fixed, with new Segments being added to the bottom”

Well, this is more or less what intended to do with this proposal :)
IMHO having an explicit Index column is useful because it makes simple to check the Segment that came out from the Spin. But if you notice my proposal is exactly what you want:

“the first Segment has Index 1, the second Segment has Index 2, and so on”

is equivalent to

“define the Spin roll in terms of table position”

and

“If the number of old Segments was N, the first new Segment must have Index N+1, the second new Segment Index N+2, and so on”

is equivalent to

“with new Segments being added to the bottom”

About the Index, I don’t want to seem repetitive :D but… Index is not the position. When the rule says “Indexes must be updated”, it does not say that Segments can be moved. It simply states in a more compact way that the Indexes must be updated to fill the gap. I could write “After the removal, the first Segment has Index 1, the second Segment has Index 2, and so on”, but this is exactly the definition of Ordered List, so for simplicity I wrote “the Segments returns to be an Ordered List”

About the rest, I agree. The possibility to add and remove is redundant. About the insertion order, maybe I had to write “The order of insertion is the order of the new Segments in the approved proposal.”