Droppables, callbacks and .data() oh my!

Droppables, callbacks and .data() oh my!

I encountered a problem yesterday using droppables.
In an application I wanted to dynamically enlarge (.animate()) some
droppables when their 'over' event was fired. I then discovered that
returning false in a event callback doesn't cancel the event (the
hoverClass is still applied).
Next I realized that the position and dimensions of the droppable
areas are stored in .data() at the droppables' creation time.
Apparently that is how ddmanager works. So then I resorted to
temporarily changing (on 'over') and then restoring (on
'out'/'deactivate') the stored properties 'proportions' and 'offset'
in .data('droppables') of each droppable that was repositioned by the
enlarged active droppable. (All my droppables were adjacent and below
each other, so this was needed to allow a seamless transition between
them.)
That's it, more or less. As a result my code got rather longer than I
intended. This experience leads me to two questions:
1) Shouldn't returning false in the 'over' callback cancel the default
behavior? (Haven't tested other events yet.)
2) Can the d&d system be changed to accommodate changes in a
droppable's size and position, ie. be dynamic instead of static?
Obviously 2) has implications beyond just the described use case. But
I don't understand the UI code well enough to risk an estimate of
feasibility...
I can however create tickets and testcases if you approve.
--