Well, some of it is my own making, test_a.ash, test_b.ash, test_c.ash for testing. I guess "I don't want to use it like you do" is a problem of my own making, too. I've got almost no interest in my last 5 scripts, nor the entire catalog of a directory. I think "only put useful stuff on the menu" is a not-unreasonable request, and both the ways we're guessing are sub-optimal and choose too broad a brush.Now I don't understand.
If things are working as designed there will be nothing in that list that is not a script file and everything in that list was either initiated directly by user interaction or a call in a script.
You might consider inspecting or clearing scriptMRUList.
I would not use "text cruft" to describe the name of anything that was important enough to put in its own script file, but if you do then I guess I understand although some of your problems are of your own making
A MRU menu is commonly used for documents. Text editors and word processors are often use them. You give up all advantages of a consistent menu (such as muscle memory of how to choose something) because the user rotates through a series of documents. Even in this case, they're often fixed at the first level, with a menu item to get to them (e.g. "Open Recent. >" in BBEdit).
Mirroring a file system in a menu makes sense when every file in a hierarchy is usefully selectable. Like a file-open dialog, where you might actually need to navigated to. We don't really do this, or need to do this.
But honestly, if you're satisfied with PM+'s solution and I am as well, maybe we should stop trying to explain ourselves to each other. It doesn't seem to be converging.