Good question I hope I can help. PARSEC was this order everything and was worked on extensively. It’s focus for us was pretty much on membership in routing and all other “stuff” it ordered was opaque (unknown to it). Most of that stuff was data and we had to remove parsec from data handling as we could not store files on the testnet. We “fixed” that issue by removing parsec from data.
Then the question is was it required, the answer is, sometimes order is required, but not always and not on every data type. So mostly no order required to say store a bit of data, but to mutate it, then we need some order or similar. This is what CRDT data types does, that is it’s function. So the opaque stuff can look after itself without parsec, in fact it needs to not have parsec as we seen.
Then membership, that is easier to solve actually and we already had solutions for membership without parsec (remember alpha II). The issue we had back then was the team had section merge in mind. This is where section merge back to a larger address space. This was a big issue I had to take up with the team, the network cannot merge backwards, it can only grow forwards. If it merges backwards then you have a more tricky situation to handle (non-linear changes). As we know if it did merge back we have data loss and that is almost guaranteed.
So no merge means relaxed requirements on order of membership events (they become much more crdt aware and always moving forward). So as alphaII grew the network still can with no parsec. However we are formalising that a little bit and if necessary have a crdt for that as well (we paid a CRDT expert to POC that).
Hope that makes sense now @Josh but shout if not.
tl;dr we are looking to depricate something we don’t use in vaults and don’t need in routing.