Two-Way Linking for Single-Select Properties

Two-way linking currently requires both sides of a relation to be multi-select (no fixed set). This blocks the most common relational shape there is: one-to-many.

Example: a Card object has a Source property that should point to exactly one Bank — a card can't belong to two banks, so single-select is the correct model. A Bank object should list all Cards issued under it — multi-select. This is a plain one-to-many relationship, structurally identical to your own flagship example, "Author ↔ Books written," once you account for the fact that most books have one primary author.

The current restriction has no functional justification. Propagating a write from the single-select side is fully deterministic:

Set Card.Source = Bank X → add Card to Bank X.Cards

Change Card.Source from Bank X to Bank Y → remove from Bank X.Cards, add to Bank Y.Cards

Remove Card from Bank X.Cards → clear Card.Source

None of these require multiple values to be written into a single-select field. The conflict that presumably justifies "multi-select only" simply doesn't occur on a well-defined 1:N relation.

The only current workaround is making both sides multi-select and relying on the user to never pick more than one Bank per Card. That defeats the purpose of the feature — it reintroduces the exact data-integrity risk (a card belonging to two banks) that structured, synced properties are supposed to prevent in the first place.

Ask: allow two-way linking when one side is single-select and the other is multi-select (no fixed set), with sync behavior as above. This unlocks the majority of real-world 1:N relations (Card↔Bank, Employee↔Department, Invoice↔Customer...) without touching existing N:N behavior.