The code above behaves exactly as I'd expect. Sterling isn't responsible for managing your relationships, only saving the ones you expose.
So in the first examle, you are linking the child to the parent, but you aren't setting the parent on the child. Sterling won't do this because it's not designed to alter your classes or make presumptions. Just because the child is in the parent list doesn't
imply that the child should also be modified to update the parent.
The same with the second example. It is behaving exactly as I would expect. You set the parent on the child. That's great - when you reload the child, you should also get a fully reloaded reference to the parent. It isn't about Sterling not understanding
relationships - you're not setting them. Forget Sterling for a minute. If you write a unit test and just set the parent of the child, the child is NOT added to the parent. You can check that in code, no Sterling. You'll have a parent with a set of empty children,
and a child with parent that points to the parent. It's your responsibility to update the references correctly, i.e. if you set the parent of the child, also add the child to the parent.
Most implementations I've seen do this provide a method on the parent like AddChild that takes care of adding the child to the children collection and then setting the parent on the child.
Again, not a Sterling issue - Sterling saves them exactly as is. I think if you debug, you'll find in your first example the child has no reference to the parent, and in the second the parent has no reference to the child because you've not set that up.