"Sticky" UUID for scripts?

I know I've been asking for a long time for the ability to macro-script objects, but I think I've tripped upon the idea that would help put it into perspective for the code-monkeys of the Second Life engine.

What if (for scripts only*) there was a "sticky" permission, which meant that the script, when copied, kept its same UUID. The same key would mean that updating the script remotely would actually work as llRemoteLoadScript() is currently useless due to the requirement of a key. If an object was being sold with a "sticky key", it would pop up in that dialogue with the permissions and even offer a button if the user wanted a full explanation of what having a sticky keyed item may entail.

But mostly I need this for my scripting. I do a load of scripting for a load of objects and more often than not, I'll be using a similar script on separate objects (using filters within the script to minimize the need of extra scripts).

So basically, I was wondering if this mere idea of "sticky keys" is appealing or possible. You may simply say "that would be difficult" and I'll completely understand. Just give me some sort of word on this feature LL Thank you!

*The idea of doing this for objects, sounds, textures, avatars has not been thought out in my head and seems quite daunting and scary.

Another thing that this would be usefull for... Multi-person scripting projects and open source scripts.

You could have one script that anyone can update/add-on to and everyone can have accesses to it.

I endorse this idea/feature.

The only problem with the "everyone can update" idea is that everyone would have to be able to see the editing in real-time for it to work without messing up. And being able to do that, in and of itself, would be a giant feat for the SL programmers.

I would go along with this idea but it seems like something that would be harder to achieve, thus I would prioritize it below my original idea above.

Thanks for your support Oz

llRemoteLoadScript() requires a scripts key?

Since when?
With my experiance with it, it accepts:

A destination object's key, a script's name, a running boolean, and an integer to pass to the script.

Sticky UUIDs would be an awesome thing. Often, you hear of the "script recalls" from various souls out there, this would allow updates without all the manual process. And as you said, multiple objects with the same script, ie a casino, could be updated with one foul swoop instead of having to visit every object. I feel the pain of this every time I want to make a change to the seats on a ride in my theme park...

I'm presently coding an auto-updater for scripted objects. I'll have it coded to the point where it can be drag-n-drop compatible, or as close as I can get it. It'll even be able to update itself, if necessary.

(EDIT: Oh. You'll still need to visit every object, but that'll be easily done easily and automatically. Just wear an attachment, and it'll do the rest.)