I tend to disagree with you. The purpose of these default behaviors is to create a quick and simple series of actions which follow (what is perceived to be) the most common usage of these actions. It is not to handle EVERY SINGLE possible usage. As such, there are many things these behaviors are not going to do that each individual user may want. In these cases, there are 3 options:
1 - learn to work with the behavior as it is.
2 - create your own behavior that does what you want.
3 - send in an enhancement request to have the behavior changed. If enough people show interest in changing the behavior to change Ashley's perceived idea of the most common way it would be used, and to add enough value to the product, then the change will most likely be made. If not, the change will only take away time for adding features that will add value. Why change something that is working as desired for the majority of users.
Developing new features adds value that makes the product more marketable and brings in income. Changing features that are working just fine for the majority of users, just because a small minority want it, does not. That being said, I believe at least some of the features mentioned by shinkan would be very useful. Especially having the fade behavior take into account the current alpha value of the object when it begins to fade.
BTW shinkan the axes drag and drop feature can be faked easily, and without too many extra events, by setting the x/y value to it's locked position every tick. If the locked axes is the y axes, set a variable to store the start y position and every tick, set the sprite y back to the stored value. If the locked axes is the x, do the same for the x. See the attached capx. You can do a similar work around to fake many of the other things you are requesting as well.