Data initialization synchronization

The current proposal has this to say about instantiation.

Data segments are initialized in their definition order

• From low to high bytes
• At byte granularity (which can be coalesced)
• As non-atomics
• An entire module's data section initialization then synchronizes with other operations (effectively, followed by a barrier)

I have two questions/observations/conversation starters about these restrictions, the second of which mainly applies to bulk memory operations (which, regardless of which solution we choose for https://github.com/WebAssembly/threads/issues/94, should have the same semantics for filling order).

1. I'm not clear on what the intention of the last restriction is. I don't think this should be here, since I've separately been told that bulk memory operations will not be thread safe, and a barrier at the end of the initialization doesn't seem to guarantee much anyway - if you're racing with the initialization, a barrier at the very end won't help you, and if you don't want to race, waiting for the initialization to finish implies a synchronizes-with edge anyway (through a wait/wake call or atomic busy wait).

2. The specification that segments are initialized in order from low to high bytes is not observable, since the individual writes themselves are non-atomic (and could be observed re-ordered). It's likely still convenient to specify it this way, but it's worth noting that this still allows an implementation to fill from high to low bytes, as a way of efficiently implementing a bounds-check using trap handlers.

Start by reading the quoted data-segment initialization rules in this issue, then review the linked threads issue #94 and the surrounding proposal text. Determine whether the synchronization restriction and stated fill order should remain, and document a resolved specification decision in the proposal.