@runrevmark will chime in and say that he still doesn't agree (yet) with widening the scope of what behaviors should be - although @monte has made the best point yet as to why it should be allowed:
FWIW... I totally understand that the behavior is just a script container but I also think there's utility in allowing any object to be that container. For example, if you decide an object script should be a behavior rather than have it's own script (say you need multiple copies) at the moment you need to cut and paste the code to a button... If we allowed any control then it's one less step... one less cognitive leap... make this group behave like that one... etc...
There is some truth here, however it would be better solved by a 'Move Script to Behavior' action (or similar) in the IDE. The point to remember is that any cognitive association that people have between the behavior script and the type of object that script is set on is wrong. There is absolutely no association.
One of the reasons buttons were chosen was that you drag them onto a card, name them and they have a name which you can see. You can have many on one card and thus making libraries of behaviors becomes easy. Yes, you could do this with other controls, but buttons are the only ones where the default state is that the name of the control is the label that you see. Thus limiting to buttons does force people into this structure to a certain degree - which didn't seem like to bad idea at the time because it works with how the engine currently resolves and manages such things and also seems like a perfectly reasonably way to organise things.
Another reason is that of cognition, again, widening the scope of what behaviors could be means that people will (more than likely) start to think that a field has to have a behavior that is also a field - even though, again, there is no association there. The behavior object is just a script container, nothing more.
Now, while at first sight, it might make sense to think that 'oh, a field should 'inherit' from a field' - if you extend this, then you get into a state where cards should 'inherit' from cards, and stacks should 'inherit' from stacks (cognitively at least). However, this doesn't really make any sense from a project organisation and editing point of view as far as I can see. Also, again, there is no inheritence (in an object sense) going on here - by using those terms and thinking of it in those ways you end up misunderstanding what behaviors actually are. (Also, remember that 6.1 will have chained behaviors which could potentially muddy cognition even further if the 'x inherits from y' meme is codified further).
Ultimately, it comes down to the fact that behaviors were designed with the best concepts available in the engine at the time. The thrust was that you'd create libraries of behavior buttons in your application on a card in a substack or separate stack, and then make the controls that use them reference them. It seemed a reasonable way to work around the fragile control references the engine has. [ Indeed, I started off with the ideal situation - behaviors were an object that was just a script, with potentially some metadata - and then worked back to a point at which it was implementable in the engine as it is ].
What was the reason behind behavior returning a rugged id?
In a loaded environment, a control is uniquely identified by the mainstack name and the id, slightly less uniquely if its a substack name and id (although the search pattern kind of helps sort that out). It is the minimal amount of information needed, and is efficient to encode in the stackfile. It was never an ideal solution, but it was the best that we came up with then.
To be honest, I don't really see a lot of value right now changing the way behaviors are referenced, nor extending them to other control types... Why? Because we have a huge re-engineering of the core of the engine around the corner that will be a base on which many of the issues with control references can be resolved in a much more elegant way. Also, it is the base upon which behaviors can finally become what they should have been - objects in their own right (thus completely eliminating any cognitive dissonance about what they are, and how the object they are relates to their function).
Is it really worth changing functionality that would potentially mean people have to update their scripts for an interim period of maybe 3-4 months, and then have to update them again? Or indeed, introducing a slight variant on a way of working which is obsoleted only a short while down the line? (I'll leave the whole, documentation, explaining, and ensuring everything still works etc. factors out for now - but they are contributory too - there is a cost to any change far beyond the cost to code it initially).
I guess my point here is that at the moment we are very much in an interim period and issues like this, 'the rugged id' and uuids have come up - and that's great - but given the huge leap the architecture is about to make it seems a little unwise to make decisions about them right now and potentially bite our noses off to spite our faces.
Now, part of the problem is that I have not yet articulated in detail what architectural changes are currently underway in the refactoring project and what this means in terms of possibilities for the future - so you guys (as yet) don't really have the same frame of reference to evaluate things as I do. For this I need a bit of time to write these things up appropriately, essentially some of the issues that have come up already are more than catered for - this includes Unicode, typing, control references and language bindings... And a lot more besides.