When choosing which structural table design for one-to-many relations
I think some of the confusion is in how you labeled things. Object A and Object B are different from Table A and Table B, because as bbaird points out, Object A and Object B are the same Object (or entity in the context of databases).
From my understanding of your problem description you can think of your data as if it were actual Parents and Children for a second to help conceptualize. Parents could go into one Table and Children in a separate Table but they share close enough characteristics because both are People and probably should live in the same primary Table. Then you can have a second Table that represents the direct relationship of a Child to its Parent. After thinking of it this way, your first design choice makes more sense (which is a pretty common design choice for a Parent-Child relationship set of data.)
Note: The above answer was prior to OP updating his question. Please see the accepted answer for further clarification.