When I first looked at the current behavior (of ui.droppable) (that is, without looking at the code), I was reasoning from the way I wanted to use ui.droppable. The initial post for this ticket was made given this background. And judging from the initial post text, I'm inclined to agree with you that it's a feature, not a bug.
However, after inspection of the relevant portions of the code, I'm no longer entirely sure that the current behavior may be the right behavior. Even though this current behavior might be `by design' –I have no doubt, judging from the code (which is very readable), that every portion of the code is well thought-out–, it is very possible that this design needs slight updating.
Call it a bug or not, I feel that the current design caches the wrong state (be it visibility, or geometry).
Even though the ticket was started for the visibility aspect of the design, it may be more obvious to show that the design fails if we focus on the geometry aspect. To show this, let's give an example of perfectly legal use of jQuery and CSS for which the current design fails:
1. If we assume that one of the ways CSS can be used, is to change the size (i.e. width or height) of a DOM element.
2. If we assume that for a droppable one can specify the `activeClass', which, as documented, is added to the droppable's class attribute during drag 'n drop operations.
Then, combining propositions 1 and 2, it's possible to define an activeClass that changes the size of the droppables as soon as the droppable becomes active. (This size increase can be used to e.g. match the size of the droppable, or to have a better user experience, because it becomes easier to drop on a bigger droppable.)
Unfortunately, the current design only considers the size of the droppable that it had *prior* to receiving the activeClass. And thus it calculates all intersections, snapping etc. with the wrong geometry.
To show this in effect, see: http://jsbin.com/ahaze4
So, while we can call this a new feature, or a new hook. Adding something new will not fix this current behavior.
If we can agree that the current design needs some rethinking and/or tweaking here and there, then we can move on to finding a solution. I'm still investigating to find one, but it isn't so obvious as it seemed at first glance.