I think your efforts to simplify have clouded things up a bit.
You've describe these relationships:
ThingsAcquired::ThingID = TheThing::ThingID
TheThing::ThingID = ThingDetails::ThingID
The names of your tables suggest that ThingID is an auto-entered serial number defined in TheThing. The relationship sketch you posted:
Things Acquired ---< The Thing ---<Details about Thing
Suggests that ThingID is auto-generated in Things Acquired. (usually, ---< means "one to many".)
WIth scripting, the "synchronized detail portal" is possible to set up, but we first have to clear up the relationships used. I'm going to switch to table names that work for me:
Invoices---<LineItems----LineItemDetails (Just name changes so far, but watch how the relationships differ...)
Invoices::InvoiceID = LineIteims::InvoiceID
LineItems::LineItemID = LineItemDetails::LineItemID.
With this change in place, I can add a different table occurrence of LineItemDetails and link it directly to invoices:
Invoices::gSelectedLineItemID = SelectedLineItemsDetails::lineItemID
Make gSelectedLineItemID a field with global storage if this database will be hosted over a network with multiple users. Enable "Allow creation of records via this relationship" for the SelectedLineItemsDetails table occurrence.
Now you place a portal to SelectedLineItemsDetails next to your LineItems portal and specify the OnObjectEnter script trigger for the LineItems portal. It should run a script like this:
Set Field [Invoices::gSelectedLineItemID ; LineItems::LineItemID]
Now clicking in a field in LineItems, brings up any existing detail records for that line item in the portal. And you can add new detail records in this portal just by entering data into the blank "add" row of this portal.