Reliable subobject creation bunch may overwrite previously received property on the actor

This seems to occur because of how reliability and the retransmission of dropped data is handled in the engine. If a reliable bunch is dropped, the entire bunch will be resent, but any unreliable bunches won't be resent if they are dropped.
Spawning a subobject creates a reliable bunch, but property changes are sent unreliably, with the replication system tracking any unacknowledged changes and rolling them into subsequent bunches.
This can result in the rare sequence of events where:
1. The server sends a reliable bunch containing a new subobject and a property change.
2. The server then sends an unreliable bunch containing another change to that same property.
3. The reliable bunch is dropped, but the client receives the unreliable bunch.
4. The server resends the entire reliable bunch, resulting in the old property value overwriting the more recent one.

On one net update, change a property to value "x" on a replicated actor, and create a replicated component/subobject on that actor.
On the next update, change that same property to "y".
Rarely (it is easier to reproduce when emulating high packet loss and latency), you can observe the property changed to "y" on the client, before it then receives and spawns the subobject and changes the property to "x."