Das hat allerdings nichts damit zu tun, dass LSL eine "Schlappersprache" ist.
Sondern mit der Art und Weise wie das mit Scripten und mit dem Inventory funktioniert.
Scripte laufen nicht alleine, sie brauchen immer ein Prim, zu dem sie gehören. Aber:
Ein Script läuft nämlich nicht im Prim selbst, sondern immer nur auf einem Simulator-Server. D.h. in einem Bereich des Speichers dort, in einer virtuellen Maschine.
Also kann ein Script auch nur laufen, wenn das Prim, zu dem das Script gehört, auf einem Simulator auch vorhanden (= gerezzt) ist. Oder wenn man es als Attachment trägt. Packt man ein Prim dann wieder ein in sein Inventory, dann wird der aktuelle Zustand des Scriptes gespeichert, d.h. der aktuelle State, die Variablenbelegung etc. (LSL Scripte sind ja im Grunde nur endliche Automaten mit Zuständen und Events). Und wenn man das Prim mit dem Script dann wieder auspackt, dann wird eben der Code des Scripts neu in den Speicher des Servers geladen und das Script wird in den Zustand versetzt, in dem es vorher war. Zusätzlich wird dann durch das Rezzen ein "on_rez" Event bzw. durch das Anziehen ein "attach" event ausgelöst.
Einfacher kann man das weitergeben aber mit einem "changed" Event erkennen:
Wenn man ein Objekt weitergibt, dann ändert sich der Owner des Scripts.
Und das führt dazu, dass das Script ein "changed"-Signal (genauer: ein Bitfield) bekommt, sobald es in den Server geladen wird und aktiv ist.
Wenn dann (Bitfield & 0x080) wahr ist, dann wurde das Objekt weitergegeben.
(0x080 ist das Bitfield für CHANGED_OWNER).
Im Inventory selbst laufen aber keine Scripte, das Inventory (bzw. der Asset Server) selbst ist lediglich eine wirklich gigantische SQL Datenbank > 500 Terrabyte, die auf einer speziellen Datenbank Hardware läuft und noch teilweise in der Amazon-Cloud gespiegelt wird. Und da steht einfach nur zu jedem Avatar und zu jedem Objekt und jeder Textur usw. drin, welche UUID wo zu gehört, welche Permissons gesetzt sind, welche Parameter das Prim hat usw.