We could lock this order into "drag to column" interactions only once those are built (i.e., not support "drag to position" -- basically, when you drop a card, we fling it into the correct position, even if that position is at the bottom of the column far off the screen). This will be somewhat confusing but maybe the least-bad of the options.

To summarize the state of the world here:

• Fix a bug with dragging between columns on a priority-sorted board.

• Clean up one more piece of code I dug out of the ground.

This now exists for priorities. I'd like to get at least one more grouping (likely: assignee) built before calling this resolved since "Priority" has some magic interaction with "subpriority". I'm moving toward getting rid of "subpriority" in D20263, but I'm not yet completely sure that it'll stick.

Drag-and-drop between columns on a priority-sorted board no longer changes priority. See T13074 for continuing adjacent work.

Some adjacent work in T13074 may build on this, and we might do "drag + shift" at some point, but this is substantially resolved.

I think I lean toward "yeah, let's get rid of this" after sleeping on it.

This [signature] bug isn't a huge issue

I wholeheartedly agree that all that proxy field mess needs to go away. With that gone the only moderately confusing part remaining would be the way in which custom fields interact with herald, email and notifications.

• Add the limits to prevent crazy behavior if you write a million rules to call a single hook/plan.

• Typo fix.