Went through feedback and did the following -

• removed custom_drop_handle entirely as it seemed redundant with the new handle_drop addition, moved the remaining terminal panel use to the items themselves, and moved the debugger UI's use of it to the SubView items
• added a parameter is_pane_target to handle_drop to discern whether an item was dropped on the item's containing pane itself or the item's tab

Also went and made the documentation for handle_drop a little more clear.

One remaining "bug" to consider is the fact that we can drag a tab/file around the terminal tab and it will show different dimming, as if that thing could split the terminal — yet all that happens is that the terminal gets that tab/file's path pasted.

Regarding this - I think keeping the regular terminal pane's splitting behaviour (only split for other terminal items under certain circumstances) is favourable - but this runs into the same issue originally causing the dropping inconsistencies where panes created by splits don't have the same characteristics (in this case, the can_split_predicate).

And again, it seems like the can_split_predicate is only used by the debugger UI and the terminal view. So, my instinct is to go ahead and make another per-Item method to handle splits. Does this sound fine?

make another per-Item method to handle splits

I guess I might miss something, but from the bird's view, this adjustment seems odd: it's the pane/pane overlay that knows whether we drop on the whole item or on its part?
If the former, then we're supposed to call item's drop handler; if the latter — we're not supposed to call anything like that at all but rather create another element?
If this is true, no extra methods is needed at all, just the pane has to get more logic added?

If I'm mistaken somehow, I wonder whether we can consider adding a parameter like "dropping into full item/dropping into part of the item" that will be handled differently by each drop handler.
Yet, I am not fond of the direction this "new parameter"/"new method" approach moves to, so if this indeed the case, it would be great to just understand what's causing issues here — and maybe it's fine to leave things as is now, as this all is definitely a very nice improvement already.
Later, we can work on a follow-up PR to fix this bug separately, to avoid bloating the current PR more.

not sure what the deal is with the git history there, oops.. I wrote a test for is_pane_target and plan on writing a different one in the morning to validate terminal dropping behaviour specifically, and I agree that the current PR is already kind of extensive enough and a follow up PR is warranted.

Thanks for all of your advice!