This is also not really a backwards compatibility issue but was present in Early Access. We felt it was worth explaining here. Emitters have a frame of delay because when the object is cloned from the reference it needs a frame for contained logic to run and make sure everything is in the correct state.
Imagine you have a switch and a spinning blade. The switch is turning the spinning blade on. When you select this contraption to be the target reference of an emitter, the spinning blade still exists in the scene as a reference object for the emitter but is now powered off.
When you emit an object the game literally does a clone operation on the reference. So now you have a copy of the switch and spinning blade but the blade is off (switch not active).
Emitting objects happens later in the frame than the code that sends signals down wires - so if we were to show the emitted objects on the frame they were emitted on you would see a stationary blade for a frame and then on the next frame after the signal from the switch had run down the wire it would start spinning. So to avoid problems like this (and much more complicated ones involving several gadgets & timelines etc.) we don't show the objects on the first frame they are emitted. They don't generate physics on that frame, they don't run logic (trigger zones/ raycasts etc).
There is an extra bit of cleverness on the second frame, when the object appears, if the emitter is also moving then we will notice the frame of lag because the object will appear behind the emitter. To compensate for that we move the emitted objects at the last minute to where they would have been emitted if the emitter emitted this frame! All velocities are recalculated too at this point.
In "Wildfire" the character loses two lives on death. This is because the character is respawned from an emitter. Logic within the Emitted character fails to communicate on the first frame causing the system to kill it again.
Emitted Timelines: We do not yet have an example of this in Community content but we had it ourselves and it is a knock on of this frame of delay. It's also the best example to visualise this emitter behaviour.
A gadget (e.g. a NOT gate) on the first frame of a timeline which is emitted will fail to trigger anything.
If you know you're up against this the simplest thing to do is to take the NOT gate off the Timeline so it triggers any logic event as soon as the logic becomes active. If you need that trigger to be a pulse you may need to add a Signal manipulator.
The Dreams User Guide is a work-in-progress. Keep an eye out for updates as we add more learning resources and articles over time.