When I use File>Export>Files…'d
the combination of folders/documents and their sub-documents produced some (relatively) few stranded documents, their paths too large (+260 bytes) to be copied, moved, backed up.
After the usual treatments –
shortening parent directory/folder names; deleting the doc/files by their 8.3 short name; RMDIR; even by SUBST’ing then trying these steps –
I did remove most of the documents.
However, one persists; the system returns that the folder is ‘not found’.
A command-line DIR /x command does not show an 8.3 short name for the folder; DIR shows the long name.
Enabling the registry/policy’s LONGPATHSENABLED did not get me access.
I’m looking at an apparently well received UNLOCKER freebie, which reportedly will also delete the folder/file:
Have folks used its abilities sucessfully, without infection?
(However I get this resolved, I will merely copy the projects #'d documents and handle them that way – I will not simply edit them in place … that would screw up the indexing – or I will consider using sync.)
(Despite the signature, I am just at 1.9.8.)
I have used Unlocker. Results are mixed - sometimes it works, others, not so much. It’s safe, though.
Ma … Thank you for your reply. 
It occurred to me not long after I SUBMITted my post – esprit d’escalier – between that and your replying …
The backup software I use (Syncback) has the ability to MIRROR the contents of one folder/drive/whatever to another. (By ‘mirror’, it means obliterate whatever is in the destination folder with the precise contents of the source folder; I’m sure other backups have the ability as well.)
I defined a new folder, put nothing in it;
I mirrored the null contents of the new folder to the folder that had the too-long file name;
Voilà, the too-long-named file was gone!
(No, I wasn’t taking a bath, nor the neighbors startled. 
)
(GONE was all I wanted: The destination folder was meant as a static structured memorial of the Scrivener project – and this time, it was a test. I realize that there would be EXPORT overhead for it during the ‘name specification’ part of the routine, but maybe L&L could skip such file-pathed files.
(Aside from the difficulty of noticing such files and paths post hoc, I could load Null Folder with replacement files, with shortened names, and perhaps shorten the path, before the MIRRORing.)
I don’t know that enabling the LongPaths enabled the software, but Hey! It worked. (I’m keeping the backup program’s ‘profile’ and ‘Null Folder’ for next time.)
Thank you again; I may look at UNLOCKER, put it in my toolbox since it comes so highly recommended! 
I do appreciate the quick reply.