If you can narrow this and figure out concrete repro, it could be very helpful.

-Rez a box.
-Add this script:

default
{
    touch_start(integer num_detected)
    {
        llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
    }
    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_ATTACH) llAttachToAvatar(ATTACH_RHAND);
        
    }
}

-Click the box.
-In your inventory, copy and paste the worn object.
-Rez the copy.
-(Detaching the original box is optional here)
-Click the rezzed copy.

Observe: The object appears as worn, at the bottom of the inventory window.

@ Fake: no prob I must confess that my description is a bit weak
Try using a no-copy object for repro.

@ Moon: thanks for posting the script. it's a bit different to my script but does the same – mine is a bit more complex.

What I did to reproduce the effect:
I put my script into a no-copy object and rezzed the object to ground. The object goes to it's supposed position in my land (a lil cave for my shoulder dragon). Then I touched my HUD-Button to tell the object to attach. The object came to me and attached. I dropped the object via right-click (pie-menu) and "Drop". Then I clicked the HUD-button again for attach.

I did this a few times and could reproduce the bug-effect only twice (so be patient).
The first time I re-dropped it after attaching and it went on as usual.
The second time I detached it via right-click in inventory and "detach": the object was lost.

I also observed that the object appeared for a nano-sec in it's supposed folder "Objects" in my inventory and then went to the bottom of the inventory window. It was marked as worn while "moving".

Hope this is helpful to someone to reproduce.

Situation A- (My Inventory Window is open to "Recent Items" but the same applies to the "All Items" folder)
1) Rez a box, name it "attach tester". Add an Attach script (mine below)
2) Accept the attach request. (it attaches and the prim appears in the Objects folder)
3) In inventory, make a copy. Label it "attach tester b"
4) Drag "attach tester b" to the ground.
~~~UNEXPECTED 5) "attach tester b" attaches but locates the prim below the Library
5) Make a copy of "attach tester b" in the Objects folder in inventory and name it "attach tester c".
6) Drag "attach tester c" to the ground.
again ~~~UNEXPECTED 7) "attach tester c" attaches but locates the prim below the Library and "attach tester b" has disappeared.
(rinse and repeat as long as sanity permits...only one "attach tester" shows up in this space)
8) At the top of the Inventory window, "File--->New Window". (nothing shows up below the Library on the second window...although it's still there in the first)
9) Repeat steps 5 & 6, renaming to "attach tester d".
same result ~~~BEGINNING TO BE EXPECTED 10) "attach tester d" shows up to replace "attach tester c" and still does not appear in other window.
10) If I attempt to move any of the "attach tester" items below the Library to the trash, my Viewer crashes after a few seconds. ( much like the sim crash attach bug we had earlier)
===================
Situation B-
1) Rez a box, name it "attach tester 1". Add an Attach script (mine below)
2) Accept the attach request. (it attaches and the prim appears in the Objects folder)
3) Detach the item.
4) Drag "attach tester 1" to the ground.
5) A new copy appears in Inventory in the Objects folder, attached.
6) Quickly drag copies of the original to the ground (in this test, i did it 20 times)
~~~ UNEXPECTED 7) Of the 20 Attach Events, 5 "attach tester 1" appear below the Library. (the number varies each time you run the test)
7) This time, all 5 "attach tester 1"'s show up in the second window, but if I open another window...they're not there.
8) I can Detach the "attach tester" from my avatar directly, but if I attempt to move it to the trash, my Viewer crashes (after 11 seconds when i tested this).
9) With or without crashing, once I relog, the attach testers are gone (without clearing cache).

________Attach script I use_________

default
{
state_entry()

}
}

on_rez(integer startParam)
{
if ((llGetPermissionsKey() != llGetOwner()) ||
!(llGetPermissions() & PERMISSION_ATTACH))

if (!llGetAttached())

}
}
}

Prolly not but I had a thought.

Has anyone considered testing if this is a run time permissions issue? The fact seems to be that all thease scripts and tests allow the permissions to go on and on after the attachment. I am not even remotely qualified to say that it is a reason for the errors but considering how complex and strict permissions are I would try testing to see if that has something to do with this problem.

/me Shrugs. (lolz)