If the “reverse lookup” column(s) will be functionally the same as the initial lookup column, then the most intuitive for me is to call them both “lookup” columns. And even present them both as if they were the original; kinda how tables and views in coda all just look like tables, so lookups and reverse lookups should just look like lookups.
I would also cast my vote for “paired lookups” over “multiple reverse lookups” … but only as a default; if possible, also give the maker the option to delete one of the paired lookups (effectively returning to a boring single lookup, which is desirable in many cases) and allow the maker to create more editable (reverse) lookup columns with different filters, like what is already possible in the detail/modal view.
In the case of a table looking up rows in itself, I think the maker must be given the choice about whether the reverse lookup column should be a separate column or the same column. (And if a different column, the maker still has the choice of deleting it if not needed.) Ie, if the lookup is mutual or not.
In a [People] table, I might make a column Buddy that is a lookup to [People], and when I set
Connor, then I want to see
Connor.Buddy immediately set to
[Ryan, Paul] if Connor and Paul were already buddies).
By the way @Paul_Danyliuk, this may be the example you were looking for where not having an editable reverse-lookup doesn’t make sense.
Then I may also want to make a Coach column that is not reciprocal; rather it should create a Coachee column as the editable reverse lookup.