Why is ordering needed? A section is responsible for its (XOR) ID-range, so if you merge two sections you would merge two non-overlapping ID-ranges with their own non-overlapping data events. (edit: this is for the data events. All other network events, like joining and leaving, are also specific to the section, so no overlapping here as well)
edit: non-overlapping ranges imply, that there are no dependencies between the events of child 1 and child 2 sections, thus those can “exist” “concurrently” => no ordering needed.
The PARSEC chain (membership) restarts after each split/merge
I think you are talking about data here. Alhpa4 is not finalised, but in any case, the idea is all data is “merged”. So for any new node it must get all the data and supply its signatures for all the data to all peers (can be via PARSEC). The current members therefor have signed all of the data blocks at all times. This allows pruning to be very efficient and also gives us a resource proof (can a node store/get all data, sign it and send back the verifications).
So a split or a merge would be a very similar issue for data as a new node would.
Yes, it depends though, data and membership are different. Membership is not so easy to prune. An app using PARSEC though could certainly make its own rules for that.
Yes, this is closer to secure message relay or distant section proofs. As messages transfer across the network then each section is given a piece of the membership data chain. It traverses that until it finds a group it agrees with (membership) and then it can traverse up the chain (mathematically) to validate the particular transaction/message being sent. This part has not ben documented very well but has been coded and tested.
So no global chain, but there is a variable global state if that makes sense. Each section can be ahead or behind of others in respect to membership, but that is fine as we transmit the parts of the chain each neighbour section needs to come up to speed and validate a message as it traverses the network. As the chain is mathematically validatable from any known position (where you know the members to be true) then you can use that part as a genesis like block and traverse chain segments with certainty they are valid.