When moving code to ED_* functions, should I follow the naming conventions there? For example, you suggested ED_object_link_modifiers() but wouldn't ED_object_modifier_link() be more consistent with the other names?

I fixed dropping on linked objects. Should the same be prevented for bone constrains in linked Armatures? I'm not familiar enough with the linking workflow.

I believe I have addressed all the issues you mentioned except for a few I have questions on:

1. Moving code to ED_ functions. I have finished doing this except for reordering data. For the reordering logic, ED_ functions already exist now because of the recent work on modifier drag&drop. These functions don't call the notifiers which is why I do the notifiers in the outliner code. For example, ED_object_shaderfx_move_to_index. In these cases it seems strange to wrap an ED function in an identical function, just with notifiers. What's the recommended approach here?

2. Cleanup of outliner_collection_from_tree_element_and_parents and similar functions. You mentioned creating a utility function to replace the 3 similar functions here. I agree that would be great. I admittedly haven't given it a ton of thought, but my best idea here requires passing in a function for identifying the desired data. So we would still need 3 functions. Is that amount of complexity preferable to the three similar functions? Perhaps there is an easier solution, I'll keep looking.

3. Data validation I added some more validation code to prevent adding grease pencil modifiers to meshes and other similar cases. One I haven't handled yet is preventing copying the two IK constraints from a bone to an object. Again, I'll see if I can find a reasonable place to put this check, but I would appreciate some input.

In D8642#213615, @Zachman wrote:

I believe I have addressed all the issues you mentioned except for a few I have questions on:

1. Moving code to ED_ functions. I have finished doing this except for reordering data. For the reordering logic, ED_ functions already exist now because of the recent work on modifier drag&drop. These functions don't call the notifiers which is why I do the notifiers in the outliner code. For example, ED_object_shaderfx_move_to_index. In these cases it seems strange to wrap an ED function in an identical function, just with notifiers. What's the recommended approach here?

I'd just move the DEG and notifier calls to the ED_ functions. Editor level functions are high-level, I think it's reasonable to expect them to do the necessary update tagging for the operations they just did.

2. Cleanup of outliner_collection_from_tree_element_and_parents and similar functions. You mentioned creating a utility function to replace the 3 similar functions here. I agree that would be great. I admittedly haven't given it a ton of thought, but my best idea here requires passing in a function for identifying the desired data. So we would still need 3 functions. Is that amount of complexity preferable to the three similar functions? Perhaps there is an easier solution, I'll keep looking.

There are a few ways we could do this, but I think just passing a callback that checks if an item meets the criteria is easiest to understand. I don't mind much having three small functions, but having almost the same iterator logic duplicated multiple times is nice to avoid.

3. Data validation I added some more validation code to prevent adding grease pencil modifiers to meshes and other similar cases. One I haven't handled yet is preventing copying the two IK constraints from a bone to an object. Again, I'll see if I can find a reasonable place to put this check, but I would appreciate some input.

I would simply disallow dragging bone constraints to objects. Only allow dragging object constraints to objects, and bone constraints to bones. Even if they are of the same type, you don't know if a constraint changes internal logic based on if it's added to an object or to a bone. And if then a bone constraint is copied to an object or vise versa, things might break.