here's a 762 gotcha that has made me insane..
try cleaning up your mre domains..
eg try creating some folders to make order out of chaos ...
and you know there's no MOVE, only a CUT (delete) and PASTE..
so holding breath at best, try CUTting a fex and PASTEing to a new folder,
and..
lo and behold
the PASTE changes the fexname...
it takes ALL OF THE DESCRIPTION IN THE PROPERTIES BOX and makes it part of the fexname!!!
Kill me now!
Can you just imagine the face on the insidious brain that planted this rotten easter egg!

In 76x we no longer truncate reports to 8 characters. We will use the full description.
A cut and paste is a DELETE and a NEW. Even in 71x, if you create a standard report of fred, then change it's description to barney, then cut it and paste it - the new HREF will be barney. So you get the same behavior in 76x, but the href name is longer.

DELETE and PASTE not NEW.
Doesn't matter that it happened in 761... Its still an insidious behaviour. Changing the description of a file using Properties, does not in fact change the fexname. Therefore the user has a reasonable expectation that COPYing and PASTEing from one domain to another will in fact keep the full nomenclature intact, ie name and description separate, as they are in the orginal.
Whether its COPY/PASTE across domains or DELETE/PASTE across folders, no matter. The carefully-learned behaviour of creating a fex with the fexname, then going back and changing the decription with the Properties box so that it sorts properly SHOULD BE RETAINED. Totally separate issue from having long fexnames. This behaviour shows all the signs of not-well-thought-out interface programming.
-s.

What I was saying is that the 71 (and 53) behavior was the same:Paste creates a new object using the description as the base of the new href. Agreed that paste could have the behavior you describe where the href is retained (we were just discussing that this afternoon independent of this post).

aha. great minds....
applause if you can put it back ...