Drag and Drop states don't function properly

To get the effect you want requires that you take control of all the triggers, the opposite of what you were hoping.  ;(

1. Under DRAG AND DROP properties, turn on the "Delay Item Drop States Until Interaction is Submitted".   This will allow you to see the items that have "snapped back" to their original positions when not dropped on anything.
2. Next, pick a drop item (Address) and add two more triggers.  (I know, I know...)
   
   This way YOU are setting the "invisible" state of these items as they are dropped, and Storyline is snapping back visible items when not dropped on one of these folders.
3. Copy those two triggers onto your other items with the same CONFIDENTIAL target, these triggers won't need editing as they pasted.
4. Copy the triggers onto one of the PROPRIETARY folder items, edit them to fit this new target, then copy those edited triggers to the other items in that folder group.
5. Then repeat with the last group PUBLIC.

This is probably a correct solution to handle problem #1. Do you agree with me that this seems like it should be out-of-the-box functionality, without having to create 24 extra triggers? To handle problem #2, I employed a similar workaround, but this time with 36 extra triggers. So whenever I pick up an object and drop it on a target item, there is a trigger to change (A) the target back to normal, and (B) the drag item to hidden. That's a total of 5 EXTRA triggers for EACH drag item. So much extra work.

Looks like you are getting a handle on it. 

The reason #1 was happening is because when you dragged an item and did not hit a target, it was setting the state to Drop Incorrect which you had an empty state, so was working as expected.  With the delay set per Jerry's suggestion, then it stays but then you have to change that on drop OR you can change your draggers to hidden when they drop on one of the 3 targets, that way you can handle that change with one trigger since you are not using the drop correct, incorrect states as long as they only have one shot at it, then you should be good

Most drag and drops are simpler than yours ;0), meaning that there is one target for each dragger, in your case they can drag to any of them, so it is more of an arbitrary sort.  

I agree that drag and drops can become cumbersome with trigger counts, I had one once with over 100 triggers, but without being able to do some basic coding to assist, this is what we have for now.

The good thing is with the new triggers panel, this can be done MUCH faster now ;0)

My suggestions above seemed to solve both problems you had presented with only the 2 additional triggers.   I'm not doing the math, so maybe we're saying the same thing.

It's a lot of work, agreed, but the triggers being copyable reduces the pain of the duplication process, IMO.

Out of the box?  I get what you're saying.  But the way the system is setup currently the 'LEGO BLOCKS" they have provided give us fantastic control and we are constrained only by our imagination.  The more they fine-tune specific behaviors, an argument can also be made that that reduces flexibility, and results in more "requests" for code updates.  You know?

So, the way it is, and with the help of the community, we seem to be able to handle most scenarios we come up with, yes?

I agree with Jerry, what we have to date is pretty awesome.  I enjoy the challenge of trying to solve the problems we are faced with and there always seems to be a solution, although sometimes it takes more than what we expect.  What is interesting is that there are many ways to do the same thing, and everyone thinks differently, so interesting to see what everyone comes up with and this is great place to learn. ;0)