I think I know what the problem is. It has to do with multithreading, which allows a program to do more than one thing at the same time.
In Buildism, the main thread handles physics and input, another thread draws stuff to the screen, and each Lua script is its own thread too. However, a lot of components of the game, like the physics engine and the navigator, don't like being accessed from threads other than the main thread (the physics engine might be asked to add a part while it is in the middle of stepping the simulation, or the navigator might have to add an object while it is already busy adding another.) So instead of doing these things itself, a script thread tells the main thread to do them as soon as it is done with the current frame.
[lua]
game.World.Box.Size = Vec2D(10, 5)
[/lua]
When you change a property (including Parent) with a script, the value of the property is changed immediately (so print(game.World.Box.Size) would always give you 10,5). But the actual change is not guaranteed to be done before the next line in the script, only as soon as possible. Usually this doesn't matter, but when you're cloning a lot of objects and trying to access them immediately afterwards it does.
The solution is to wrap all of the code that needs to access the cloned objects in
[lua]
game
cheduleTask(function()
end)
[/lua]
This tells the game to run your Lua code on the main thread, and when you change the Parent property it will detect that it's running on the main thread and do the change immediately instead of as soon as possible.
