These aren't really related from a backend viewpoint, even though they're closely related from a UX viewpoint.

oh ok, i guess we should... catch this error and give a give a friendly message?

When you drop a card into a column, we send something like "alincoln dropped card X into column Y below card Z" to the server.

If card Z has moved to a different column (in another window, or through racing), we hit this.

I think the cleanest fix is to instead send "alincoln dropped card X into column Y; on the client screen it's below cards: Z, U, V, Q, R." Then we go through that list of cards until we find one that's still in the column, or treat the action as "dropped at the top of the column" if we fail to find any valid cards. I think that will do what the user wanted like 99% of the time, and be obviously ambiguous the other 1%.

This also touches T10333: if you drop below card Z in group G (say, "High Priority" or "Assigned to alice"), I think intent is always to end up in group G even if card Z has moved from that group.

That is, if users do this:

• Card Z is in "Low Priority" in column "Backlog".
• User A loads the workboard.
• User B loads the workboard.
• User A moves Card Z to "High Priority" in "Backlog".
• User B (who still sees Card Z as "Low Priority") move Card Y from another column to "Backlog", placing it under Card Z.

In this case, I think we'd currently change "Card Y" to be "High Priority", but we would more faithfully reflect intent by keeping it in the "Low Priority" group and choosing a fallback card for purposes of positioning.